|
I have question about MySQL Cluster: I am only asking, if solution like this is possible to achieve with MySQL Cluster. |
|||
|
|
|
MySQL Cluster FAQ states that it is possible to have a database bigger than available memory, but the documentation referenced from the FAQ entry states that only non-indexed columns of NDB tables can be stored on disk. |
|||
|
|
|
You can have a bigger dataset than you have physical RAM by identifying table data to be stored on disk. Non-indexed attributes can selectively be made to reside on disk but indexed attributes are always in memory. The larger the database and the more indexes you have on the tables, the more likely it is that you will need more memory or hosts. Similar to most disk-based DBMSs, there is a LRU (Least Recently Used) buffer cache that caches hot pages. When reading a record containing disk-based data a lookup is made in the buffer cache to see if the page exists there. If it does not, then the record data has to be read from disk. At some stage the buffer cache is check pointed and all the dirty pages in the buffer cache are written back to a table space. The table space together with the available RAM for the indexed attributes defines how much data you can store in a disk data table. This means that the same performance limitations exist for disk data tables in MySQL Cluster as traditional disk-based DBMSs. The bigger the buffer cache the better, as there is a risk of becoming disk I/O bound. Tables which are subject to a lot of random access, and have strong requirements on performance and response times are better designed as in-memory tables in order to avoid being disk I/O bound. The ndbinfo.diskpagebuffer table provides information on the effectiveness of this cache; users of MySQL Cluster CGE can also see this information presented over time through MySQL Enterprise Monitor graphs as described in http://www.clusterdb.com/mem+/ |
|||
|
|
