document database: All content tagged as document database in NoSQL databases and polyglot persistence
I have been trying to avoid graph “intro” slides and presentations.
There are only so many times you can stand to hear “…all the world is a graph…” as though that’s news. To anyone.
This presentation by Luca is different from the usual introduction to graphs presentation.
Original title and link: Why relationships are cool… Relationship in RDBMS vs graph databases ( ©myNoSQL)
In two posts, the Tokutek guys are explaining how transactions work on TokuMX, the replacement engine they are proposing to MongoDB users—remember that Vadim Tkachenko (“MySQL Performance blog“) called TokuMX the InnoDB for MongoDB?:
- For each statement that tries to modify a TokuMX collection, either the entire statement is applied, or none of the statement is applied. A statement is never partially applied.
`, androllbackTransaction` have been added to allow users to perform multi-statement transactions.
- TokuMX queries use multi-version concurrency control (MVCC). That is, queries operate on a snapshot of the system that does not change for the duration of the query. Concurrent inserts, updates, and deletes do not affect query results (note this does not include file operations like removing a collection).
- cursors represent a true snapshot of the system
- simpler to batch inserts together for performance
- simpler for applications to update multiple documents with a single statement
- no need to combine documents together for the purpose of atomicity
✚ I’d find TokuMX’s transactions even more interesting if they would work by default at a shard level instead of cluster level. Users would need to manually configure cluster-wise transaction thus remaining in control of the performance and availability.
✚ I still have my doubts about TokuMK’s positioning, but that’s a business & marketing story.
Original title and link: TokuMX transactions for MongoDB ( ©myNoSQL)
As you can see the SSL overhead is clearly visible being about 0.05ms slower than a plain connection. The median for the inserts with SSL is 0.28ms. Plain connections have a median at around 0.23ms. So there is a performance loss of about 25%. These are all just rough numbers. Your mileage may vary.
Some of you may recall my security webinar from back in mid-August; one of the follow-up questions that I was asked was about the performance impact of enabling SSL connections. My answer was 25%, based on some 2011 data that I had seen over on yaSSL’s website, but I included the caveat that it is workload-dependent, because the most expensive part of using SSL is establishing the connection.
These 2 articles are diving much deeper and more scientifically into the impact of using SSL with MySQL. The results are interesting and the recommendations are well worth spending the time reading them.
Original title and link: The SSL performance overhead in MongoDB and MySQL ( ©myNoSQL)