t__crayford

Post author/founder of Yeller here:

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.

Hi (author/founder of Yeller) here.

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.

I've used this library a bunch with decent success. Most recently on an API client for my current product: https://github.com/yeller/yeller_node (see https://github.com/yeller/yeller_node/blob/master/spec/integ... for the tests in question). Very happy with it so far!

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).

Nice! I wholeheartedly agree - even so much I wrote a thing about this a while back: http://yellerapp.com/posts/2014-08-11-scientific-debugging.h...

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.