Huh, interesting. That's my setup as well. I'm not super great at CSS (yet), so not too surprised by a few minor visual bugs like that. I'll fix it soon. Thanks so much.
You're totally right, I need to change the wording there. The marketing site doesn't run over https - I'm bootstrapping, with relatively limited funds, and so can't properly afford the SSL costs for a CDN (my current one wants to charge $600 or so a month for serving ssl requests).
The webapp and the api are all HTTPS only.
I should change the wording on that page to reflect that.
It's a B-tree alike, with a fixed depth of 3, built on top of cached (at the query layer), immutable storage. There's a "atom" stored in consistent storage (and in memory on all processes), with a UUID pointer to the immutable tree. The root of the immutable tree contains pointers to "directories", which are the second layer. The third layer contains the actual data, in chunks of ~1k facts per segment. All of the immutable tree is stored in riak/dynamo/cassandra/postgres or whatever (it's just binary blob storage by k/v, so it's pretty easy to implement). There are several indexes that are in different orders, all of them covering indexes.
The transaction log also goes into a tree, but that tree is structured rather differently (for performance reasons). For example, it maintains a "linked-list" (in storage!) of the latest N transactions, which it then rolls up into one tree node once that list gets to a certain size.
The missing part about how transactions are available "immediately" (which is a word that doesn't make sense for a distributed database ;), is that the transactor (which is a separate process/system from those that answer questions), streams new transactions (as they happen) to the query boxes (known as "peers"). A peer is just your usual client process: for example your Java frontend webserver process (at this time only JVM clients are properly supported in this model)
Indexing is done in the background every ~33mb of transaction data (in the transactor) (and it allows that to build up during new indexing jobs, applying back pressure if it gets too much in memory data). Indexing isn't append only at all - it creates a new tree (that very often shares a lot of data with the old tree, however).
To answer queries, the "peers" merge the new transactions they've received (that are in memory), with the durable index.
That's how new transactions get seen quickly - the peers have recent data in memory, and other data in long term durable storage.
Transactions are visible as soon as the transactor's streaming sends them to peers. There is also a mechanism to say "wait until this transaction has arrived at this peer" before querying.
Because the data in the indexes is immutable, it's trivial to cache in the client processes. Many smaller databases can fit entirely in memory, in which case querying only hits main memory, not the network on the peer process, which makes them (potentially) many orders of magnitude faster than querying a traditional RDBMS).
First, I'm hesitant in making this post, as I do not intend to belittle anything getting done. Sounds like this team is working very hard on solutions, and that is ultimately awesome. And, serious thanks for the details. Sounds very fun. (And, over my head.)
I am curious on why you have "potentially" in parens. Is this just not panning out in measurements? Are these not techniques that older products could have already subsumed into their repertoire?
A lot of this reads like RISC versus CISC debates. There are virtually no techniques that one side can claim monopoly on. So it is not surprising to see that picking the acceptable tradeoffs and combining solutions appropriately is often very effective.
I'm working on my startup: http://yellerapp.com. It's a smarter exception tracker, with a severe emphasis on helping you diagnose exceptions faster through better analysis.
Last week I shipped time series graphs for all your exceptions, and now I'm working on some new client libraries.
like always, software development is tradeoffs. For this product, where I have a hosted thing, which uses riak (which has a very limited set of functionality), but may eventually offer an enterprise thing that uses a traditional sql database (just as a k/v store though). Furthermore, the ability to compose e.g. caching on top of storage has been super useful
if your needs are simple, why reach for a higher layer of abstraction, rather than just rewrite the simple layer in the first place? You will quickly find that your abstraction library doesn't handle everything you were thinking of post-migration anyway.
That doesn't help if I want to support both kinds of installs using the same codebase. I'm pretty confident with this set of abstractions at this point - I've implemented maybe 15 different storage backends or storage wrappers, most of which were super easy, and I've never changed app code based on storage changing out from underneath it.
Huh, interesting. That's my setup as well. I'm not super great at CSS (yet), so not too surprised by a few minor visual bugs like that. I'll fix it soon. Thanks so much.