Wow, that is quite a surprise. You are right. Aria 1.5 is current. What a shame. When is Aria 2.0 estimated for release? http://kb.askmonty.org/en/aria-faq/ Looks like I need to begin to try XtraDB on RAM Disk to see what performance I get with that and basically throw out Aria until 2.0. I NEED row level locking on RAM DISK tables for performance reasons. Another research project for today. On 9/9/2012 12:44 AM, Sergei Golubchik wrote:
Hi, md!
Does anybody have any thoughts on what would be involved with getting Aria Tables to have an option to be memory only (Fully cached with no disk writing, power off means data loss) It should be quite easy, I suppose. One would just need to add some
On Sep 08, md@rpzdesign.com wrote: option that would prevent flushing pages of these tables from the page cache down to disk.
ARIA support row locking instead of Memory Tables which only have Table locking. Table locking sucks for anything that is heavy read/write. Aria does not support row locking.
Right now I am using RAM DISKs to store my memory based ARIA tables so I can get decent speed for heavy read/write sections of the DB.
But there is a bit of a operations headache where I have to allocate the RAM disks on system boot and the storage strategy of Aria does not release disk blocks when records are deleted, those spaces are left for future records by setting the deleted flag back to undeleted. So the memory pool is not used very effectively.
So deleting records from a RAM disk ARIA table means that I have to vaccuum the tables using ALTER table every so often or I could run out of memory. (Very bad for ramdisks)
If the ARIA cache routines could allocate memory dynamically from the global heap and return the memory upon delete operations, that would be a better options. And of course, no data is written to disk, just kept in cache. Allocating memory dynamically would be more difficult that simply not flushing pages. But anyway, the point is moot, because Aria uses table-level locking.
Regards, Sergei