Achieving 100M database inserts per second using Apache Accumulo and D4M [pdf]
ieee-hpec.org
ieee-hpec.org
But the big issue with databases I've worked with is not how many inserts you do per second, even spinning rust, if properly reasoned can do -serious- inserts per second in append only data structures like myisam, redis even lucene. However the issue comes when you want to read that data or, more horribly, update that data. Updates, by definition are a read and a write to commuted data, this can cause fragmentation and other huge headaches.
I'd love to see someone do updates 1,000,000/s
That forces the latest-version resolution into a read-side problem - systems like that cannot handle any sort of complete table-scans but can only really work for a pre-known key.
With a known unique key, this is somewhat possible to use systems like this, but extremely expensive when what you need is BETWEEN '2017-01-01' and '2017-01-02'.
If you use a clustering key, scans become trivial within a given partition.
With Cassandra (well most nosql dbs that I've run into) you model your data in the db by the queries. So if you want to scan by date then you create a new table (or a materialized view) with the date as the key you query for. Though even for then you have to keep in mind the amount of data to make sure you don't have too much data per partition and hotspots.
/s
Our graph store (HBase, SSD) on 10 nodes can easily support 3M edges/s read/stored, but thats ~40k RPCs/s given our column sizes and average batch size.
A log structure for your database would make the update case more similar to the append case, wouldn't it?
(There are definite limits to that technique, but it does work for eg some file systems---which are also a type of database.)
> but it does work for eg some file systems---which are also a type of database
No mainstream FS uses the txn log as a primary store. The log(s) are only around for active writes to metadata, as soon as the second write is out the spot in the log can/will be reused. Similar to the clean up case FSes try to batch as many ops as they fit into their log(s) before flushing the transaction.
Apart from the CoW herd (ZFS, btrfs, HAMMER) most FSes either can't or won't journal data by default anyway. -- Which is a fairly often overlooked point, many people seem to assume that a journaling FS means that everything, include their application data, is journaled, which isn't just wrong, but can also be a rather dangerous assumption; depending on application.
Two amazing facts about MySQL Cluster: (1) It's open source (2) It's never penetrated the Silicon Valley Echo Chamber, but is still the world's best DB for write-intensive transactional workloads.
I feel like it would be more popular if people actually wrote about how they're using it. But how do you start when even basic configuration bugs are still open without progress: https://bugs.mysql.com/bug.php?id=28292
(this was a few years ago or so, maybe things changed)
But if you really want to squeeze performance out of it, read Mikael's blog: http://mikaelronstrom.blogspot.se/ and Frazer's blog: http://messagepassing.blogspot.se/
The Lightning Memory-Mapped Database (LMDB) https://www.youtube.com/watch?v=Rx1-in-a1Xc
ScyllaDB http://www.scylladb.com/
What is impressive I guess is that they can sustain 1M updates/sec at a 99.9th percentile update round-trip of ~10 microseconds or so, with medians at around ~4 microseconds.
Standards for Graph Algorithm Primitives http://www.netlib.org/utk/people/JackDongarra/PAPERS/GraphPr...
GraphBLAS: A Programming Specification for Graph Analysis [video] https://www.youtube.com/watch?v=6tnzSiq8QBo
Graphulo: Graph Analytics in Apache Accumulo [video] https://www.youtube.com/watch?v=nsmFjZNl60s
https://github.com/Accla/graphulo
MIT D4M: Signal Processing on Databases http://www.mit.edu/~kepner/D4M/
https://ocw.mit.edu/resources/res-ll-005-d4m-signal-processi...
Video Lectures: https://www.youtube.com/watch?v=zNGKX-4PRsk&list=PLUl4u3cNGP...
Book: Graph Algorithms in the Language of Linear Algebra http://epubs.siam.org/doi/book/10.1137/1.9780898719918
D4M: Bringing Associative Arrays to Database Engines (2015) [pdf] https://arxiv.org/pdf/1508.07371.pdf
I am using this pattern in risk, fraud and commerce and once new members in my teams get over the mental barrier of decoupling the append only log from state, it all just clicks for them.
I feel like there's very limited applications where all out speed is important and it's better to use a database than just do the operation yourself in ram and save the network overhead.
You can insert billions of items per second into a hashtable, and when you're working in your own app memory transactions aren't needed.
An important point is that they disabled all of the durability, replication, and safety features. Graph500 records are quite small so that insertion rate given the size of their cluster implies average throughput that is significantly less than line-rate.
I had not heard of it before and the line "widely used for government applications" made me wonder why I hadn't. I'm a consultant working with graphs in Norway and this database is completely new to me.
With Cassandra you can goto DataStax and if you are using HBase often you are using Hadoop therefore you can get support from Hortonworks or Cloudera.
You are right that restart survivable persistence has absolutely nothing to do with it.
People used to get filthy rich (hi there Larry) building databases (which has all sorts of data access & management goodies) until 21st century came along and in the name of "progress" a hashtable with an HTTP interface was called a "database". Of course as nod to the said filthy rich guys from the 20th century we called them "noSQL" "databases" so as to let them continue to charge money from all those silly people in the 20th century that built their information systems on (the now "defunct" :) "databases".
The other way around. All the in-memory stuff is nothing but a cache, distributed or not.
Datastore is a layer, a set of routines and interfaces, which maintains persistent storage, such as Informix C-ISAM.
I am old-school Informix DBA, so we knew that Larry has been a cheater.
That's flat out wrong.
A cache is a limited store that maintains a sub-set of the data that has been placed in it. Typically the eviction policy is temporal.
A database or datastore on the other hand requires explicit removal of data that has been placed in it.
p.s. Which is why we can meaningfully talk about "cache misses" in context of a perfectly functional cache, but "missing" data in a database is generally discussed in context of a buggy datastore or database.
p.s.s. Most certainly we can have pure in-memory datastores/databases, as semantics of a database are orthogonal to its datastore component. And you don't have to take some random hn user's word for it. Go ahead and ask Michael Stonebraker. :)
Oh, come on. Old time RDBMS have been designed to survive a sudden power outage - the system would rollback all the partially committed transactions to recover to the consistent state of the database.
The durability and data consistency is what defines a database in the first place.
For cache vs. database metaphor - think of the difference between a RAM-disk and HDD. This is fundamental difference. Protocol details are irrelevant.
This is why, say, sqlite is a database, while redis is not.
Data is implicitly removed from a "cache" in course of normal operation.
In-memory database is as much a database as a RAM-disk is a disk.
It is certainly true that many pure mem vendors out there are playing fast and loose with terminology, but if one were to accept your assertions, then when the day arrives when spinning disks are antiques then I guess we no longer would have databases.