We can always use a structure database in an unstructured way, I think it's workable in theory, but why choose MySQL? As discussed some while ago, any LSM structured database design will suffer in performance due to write amplification, is that the reason goes to MySQL only about prevent LSM? Or try some B-tree like structure? If so ,maybe LMDB is a better choice?(although it's not yeet self-proven as production ready ) -----Original Message----- From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel-owner@xxxxxxxxxxxxxxx] On Behalf Of Haomai Wang Sent: Saturday, January 31, 2015 12:18 AM To: Chris Pacejo Cc: Sage Weil; ceph-devel@xxxxxxxxxxxxxxx Subject: Re: [ceph-users] keyvaluestore backend metadata overhead Although I still have some confusing, it's glad to see more attempts. More test results are welcomed! On Sat, Jan 31, 2015 at 12:08 AM, Chris Pacejo <cpacejo@xxxxxxxxxxxxxxxx> wrote: > On Fri, Jan 30, 2015 at 10:52 AM, Haomai Wang <haomaiwang@xxxxxxxxx> wrote: >> It's really a surprise that you impl a MySQL backend. Could I know >> the purpose? Because it may not fit with keyvaluestore I think. > > We've found it to perform better (in isolation) than LevelDB. We were > able to map KeyValueDB's interface to it fairly painlessly, and I > believe correctly. (The only major catch was that we needed to buffer > operations within a transaction and execute them all at once on > submit, to prevent MySQL unnecessarily holding locks for the duration > of long-lived transactions.) > > >> You can simply calculate the sum of submit_transaction_sync consuming >> time, it would be the multiple of the op thread number. > > I will try this, thanks. -- Best Regards, Wheat -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
