py4j กับ mondrian

เนื่องจากส่วนตัวไม่ค่อยอยากหัดเขียน java ดังนั้นเวลาใช้งาน mondrian จึงเกิดปัญหามากมาย แต่พออ่านอันนี้แล้ว สำหรับสาวก python ก็สามารถใช้ python เรียก mondrian ได้เหมือนกันแฮะ

http://stackoverflow.com/questions/3793215/query-olap-mondrian-mdx-xmla-with-python-interface

คิดแบบเบ็ดเสร็จ ย้อนกลับมาหาวิธีการและแหล่งที่มา

วันนี้เป็นอีกวันที่ต้องปวดหัวกับคำถามที่อยู่ ๆ ก็โยนข้อมูลดิบและสิ่งที่ต้องการมาให้

ข้อมูลดิบเป็นข้อมูลที่ได้มาจากระบบ Point Of Sales แต่สิ่งที่อยากได้คือการวิเคราะห์ที่ได้จากข้อมูลนั้น วิธีการที่ดูแล้วจะช่วยให้หยิบข้อมูลในแต่ละมุม (dimension) มาเปรียบเทียบและหาคำตอบที่ต้องการก็คงไม่พ้นการใช้ Cube เพราะข้อมูลมันมีจำนวนมหาศาล

ลองนึก ๆ ดูแล้วที่เค้าเรียกว่าวงจรการวิเคราะห์​ (Cycle of Analysis) น่าจะจริง

1. ลองนำข้อมูลที่ได้มาทำเป็น Data Warehouse
2. แล้วเลือกชุดข้อมูลที่ต้องการมาทำ Cube
3. ผลที่ได้จาก Cube จะบอกว่าเราจะทำอะไรต่อ
4. แล้วก็กลับไปทำของ 2 อีกครั้ง 

แต่ก็เหมือนมันเป็นการแก้ปัญหาที่ปลายทางมาก ลองนึกใหม่ว่าทำอย่างนี้ได้หรือไม่

1. ถามตัวเองว่าเมื่อทำระบบแล้วมันจะได้ข้อมูลอะไรบ้าง
2. เมื่อได้ข้อมูลนั้น ๆ แล้วจะทำอย่างไร
3. แล้วก็ออกแบบวิธีการที่จะได้มาซึ่งข้อมูล
4. พัฒนาระบบ

Memory พอไหม

มาดูกันว่าค้นนี้เค้าตอบว่าอย่างไรบ้าง

> Mem:  16299476k total, 16198784k used,   100692k free,    73776k buffers
> Swap: 16787884k total,   148176k used, 16639708k free, 15585396k cached
>
>  PID   USER      PR  NI  VIRT    RES   SHR   S    %CPU  %MEM    TIME+    COMMAND
>  3401 postgres   20   0   4288m  3.3g    3.3g   S     0         21.1         0:24.73   postgres
>  3397 postgres   20   0   4286m  119m  119m  S     0        0.8           0:00.36   postgres

> PLease help me to understand how much memory does 1 Connection Uses and how
> to use Server parameters accordingly.

OK, first, see the 15585396k cached?  That's how much memory your OS
is using to cache file systems etc.  Basically that's memory not being
used by anything else right now, so the OS borrows it and uses it for
caching.

Next, VIRT is how much memory your process would need to load every
lib it might need but may not be using now, plus all the shared memory
it might need, plus it's own space etc.  It's not memory in use, it's
memory that might under the worst circumstances, be used by that one
process.  RES is the amount of memory the process IS actually
touching, including shared memory that other processes may be sharing.
 Finally, SHR is the amount of shared memory the process is touching.
so, taking your biggest process, it is linked to enough libraries and
shared memory and it's own private memory to add up to 4288Meg.  It is
currently actually touching 3.3G.  Of that 3.3G it is touching 3.3G is
shared with other processes.  So, the difference between RES and SHR
is 0, so the delta, or extra memory it's using besides shared memory
is ZERO (or very close to it, probably dozens or fewer of megabytes).

So, you're NOT running out of memory.  Remember when I mentioned
iostat, vmstat, etc up above?  Have you run any of those?





เดี๋ยวมารอดู iostat กันต่อ

Write locally, Read Globally

จากแนวคิดนี้ fb engineer ก็สามารถนำมาใช้งานกับระบบที่เรามีอยู่ได้ง่าย ๆ ก็คือการปล่อยการ update ข้อมูลเป็นของระบบฐานข้อมูลไป ส่วนการอ่านค่ามาใช้งานก็ให้อ่านได้จากหลาย ๆ ฐานข้อมูล

At Facebook, traditionally, writes are applied to one database and asynchronously replicated to databases across all regions. This makes sense as the write rate is normally much lower than the read rate (users consume content much more than they produce). A good way to think of this approach is "read locally, write globally".

Basic has no boundaries.

Postgresql เมื่อ index bloat (บวม)

เมื่อเราใช้ Postgres ไปนาน ๆ แล้ว สิ่งที่ติดตามมาคือ

1. จำนวน record ที่เพิ่มมากขึ้น
2. ขนาดของ index ที่มากขึ้น
3. ขนาดของ dead rows ที่มากขึ้น
4. ค่า free space map ดูว่าจะไม่พอแล้ว ในเวอร์ชั่นที่ต่ำกว่า 8.4
5. มันสายไปแล้วถ้าคุณลืมเปิด autovacumm

หลาย ๆ คน อาจต้องยอมทำ VACUUM FULL แต่ปัญหาก็ตามมาคือ ระบบผมหยุดไม่ได้!

ส่ิงที่ต้องรีบดำเนินการโดยด่วนคือ

1. เพิ่ม free space map
2. เปิด auto vacuum
3. จากเดิมที่ใช้ DELETE TABLE tablename; ก็เปลี่ยนเป็น TRUNCATE TABLE tablename;

อ้างอิงจากอันนี้ http://gkoenig.wordpress.com/2009/11/24/postgres-and-bloated-table/

postgres and bloated table

November 24, 2009 in open source, PostgreSQL

From time to time there are news/messages about bloated tables in postgres and a thereby decreased performance of the database.

The postgres-wiki contains a view (extracted from a script of the bucardo project) to check for bloat in your database here

For a quick reference you can check your table/index sizes regularly and check the no. of tuples to assume where bloat comes in.

e.g. check size of your tables and indexes:

SELECT relname AS table_name,

pg_size_pretty(pg_relation_size(oid)) AS table_size,

pg_size_pretty(pg_total_relation_size(oid)) AS total_size

FROM pg_class

WHERE relkind in ('r','i')

ORDER BY pg_relation_size(oid) DESC;

check no. of tuples

SELECT relname, relkind, reltuples, relpages

FROM pg_class

ORDER BY relpages DESC;

If you’re facing such a situation you have to check your (auto)vacuum settings and if it’s working correctly.

Starting with Postgres 8.3.x the autovacuum daemon works reliable for most cases and should be enabled. On some workloads a manual vacuum is needed anyhow. In combination with setting the (auto)vacuum parameters you have to consider the Free Space Map (FSM) parameter.

Open your postgresql.conf and check it out (every parameter has a very good comment there):

* enable autovacuum and log every run > 1 sec.

autovacuum = on

log_autovacuum_min_duration = 1000

fine tune when autovacuum will check the tables. The number is the fraction of the table size which needs modified data to run an autovacuum.

Apart from the bloated-table/index stuff, for the query planner it is very important to have up-to-date statistics. If you need an analyze more often, shrink the number to e.g. autovacuum_analyze_scale_factor = 0.02 and the tables will be autoanalyzed more often

autovacuum_vacuum_scale_factor = 0.2

autovacuum_analyze_scale_factor = 0.1

prevent autovacuum from running too often

autovacuum_naptime = 1min #time between two runs

And don’t forget to check your postgresql.log file for any hints the database system provides.

Regarding bloated tables I detected something like:

WARNING: relation "public.table_one" contains more than "max_fsm_pages" pages with useful free space

HINT: Consider using VACUUM FULL on this relation or increasing the configuration parameter "max_fsm_pages"

A “normal” vacuum wouldn’t help in this case because it doesn’t release the pages to the os, they will only be marked as free in the FSM (Free Space Map).

If your FSM isn’t big enough your tables will be bloated even with running autovacuum and perhaps manual vacuum, because the pages with no longer needed data cannot be marked as free and therefore never be overwritten.

One solution would be to run a

vacuum full verbose analyze table_name

This “defragment”-command marks unused pages as “can be overwritten” and moves pages from the bottom into this marked pages. => The table size will shrink

! But be aware: vacuum full locks the table exclusive. Consider running this command in maintenance windows or during night.

You should also keep in mind to “defragment” bloated indexes with

REINDEX INDEX indexname # recreate index explicitly

REINDEX TABLE tablename # recreate all indexes for this table

framework!

ช่วง 2-3 สัปดาห์ที่ผ่านมาใช้เวลาส่วนใหญ่กับการทำความเข้าใจกับระบบ ERP ซึ่ง หลาย ๆ คนคงหาหนังสืออ่าน แต่ผมมีเวลาน้อย ก็เลยอ่านผ่านการใช้งานโปรแกรม

นอกจากแนวทางการสร้าง Sofware ที่เป็นแบบ Opensource แล้ว เมื่ออ่านเสร็จแล้วก็ค้นพบว่า การวางรากฐานที่ดีในการพัฒนานั้น จะทำให้ การต่อยอดของ Software มีประสิทธิภาพดีด้วย และสิ่งที่เรียกว่ารากฐานนั้นก็คือ FrameWork นั้นเอง

หลาย ๆ คน พัฒนา Application ไป ก็พยายามสร้าง function ต่าง ๆ ขึ้นมามากมาย ท้ายสุดก็เกิดเป็น Framework ในการพัฒนาขึ้นมา ซึ่งผมก็เป็นอย่างนั้นเหมือนกัน

แต่ที่น่าแปลกใจคือ คนริเริ่มพัฒนา OpenERP นั้น เค้าศึกษาขบวนการทางธุรกิจ ได้อย่างมากมายได้อย่างไร

How to Install OpenERP on Leopard 10.6.4 with VirtualENV

Over 2 weeks i spent time to install OpenERP on my MAC.
Luckily i found the way.

First i try to install all with python2.6. Unfortunately OpenERP 5.0.14 work well with python2.5. Please try my step

1. you need python2.5!
2. you need postgres
   
3. install VirtualENV from fink
4. cd
   
5. virtualenv openerp-py25
6. source openerp-py25/bin/activate
   
7. install these packages by pip or easy_install
   
• Babel
• Beaker
• CherryPy
• FormEncode
• Mako
• MarkupSafe
• PIL
• PyChart
• PyXML
• pydot
• pyparsing
• reportlab
• simplejson
• psycopg2
  
8. # Download openerp server
   
9. $ bzr branch lp:openobject-server/5.0 openerp-server-5.0
10. # Install openerp server
11. $ cd openerp-server-5.0
12. $ python setup.py install
    
13. # Download openerp web
    
14. $ bzr branch lp:openobject-client-web/5.0 openerp-web-5.0
15. # Install openerp web
    
16. $ cd openerp-web-5.0
17. $ python setup.py install
18. # Start Open Server and web
    
19. $ openerp-server --db_user=openuser --db_password=
20. $ openerp-web
21. #Open Safari > http://localhost:8080 with username admin password admin
    

ref: http://devteam.taktik.be/index.php?/archives/9-How-to-install-Open-ERP-5.0.0-on-Mac-OS-X-10.5-Leopard.html