61–70 of 75 posts
I don't really get all the whining about the name, I even kind of like it. It fits well with their narrative. Besides, they could've called it PoopDB and I still would use it if it survived a nuclear blast and had joins. I couldn't care less about the name. But apparently I'm in a minority...?
I have serious problems with the name of this, even opening this post is giving me real trouble. I can't believe someone thought this was a good idea for a name. No matter what the tech is, or how good it is, I will NEVER be able to use this.
Great news! I still don't understand why HyperDex (which has similarities in design and goals) has existed for years and nobody seems to know about it. Is this because it doesn't support SQL? http://hyperdex.org/
On the other hand, the author (or authors) seem completely unresponsive about some things. Their Homebrew package's Ruby support is still broken a year after reporting it [1]. The Homebrew package is also ancient (1.4.4 instead of 1.8.1); I did a PR [2], which requires that the authors to roll a release of their fixes to HEAD of libpo6 [3]. All of this has been ignored for some time.
I'm just worried that the project, which seems to be maintained by just one developer, is languishing. Very little commit activity, lots of open issues, lack of attention, etc.
[1] https://github.com/HyperDex/homebrew-hyperdex/issues/10
What are the current performance characteristics in terms of number of select and insert per second per node ? Does anyone have synthetic benchmarks published ?
I still don't get it why people get so excited with every new even-more-scalable DB yet at the same time completely ignore what's happening with things like graph DBs or hybrid-document-graph DBs that seem so f cool! Also... why would you want to live WITHOUT ANY JOINS nowadays?! Unless the scale requirements actually prohibit it, and let's face it, 99% of what people are doing is not even close to "big data" on mode…
* Document or SQL Storage * Integrated Full Text Search * Can transparently survive a node going down (load balancer or client driver support) * Highly consistent by default, or allow operation level quorum settings * DR options with minimal lost writes * Transaction support * Hosted * Affordable for small businesses with low average load, but including the occassional peaky or seasonal issues (large bulk imports, auto/consumer/product/etc-show traffic spikes for a few days, etc)
Cloudant meets everything but Transactions. But that's a big one.
Most databases you might think of don't satisfy the Hosted option. And considering how easy it is to loose other items on the list through misconfiguration or maintenance issues, that's a lot more of a core feature than might be obvious for a small shop. It's great if node failure is transparent in theory, but if it doesn't work in practice it may as well not exist.
Most of the rest don't integrate full-text-search. That's huge. It means a ton of concerns move from the database vendor, to you, the application developer. Any database that doesn't (at least plan to) integrate full-text-search is one with a much higher development and operations cost.
And the number of databases that promise to (eventually) deliver distributed SQL? There was 1 a few years ago (AFAIK) that met most of those: FoundationDB. Never to be heard from again. :-)
I don't need a GraphDB for my CMS-like sites. That's just not a very good fit. And working without JOINs (though it sounds like they're on the roadmap here) is not as onerous as you'd imagine for many sites, and it often brings along the side-effect of forcing you to write a much more efficient/fast product against denormalized data.
So any database that promises to check most of those boxes is worth keeping an eye on (IMO). Though the things that kill most solutions candidacy for me are:
- lack of integrated Search
- lack of Hosted/Managed option
I still don't get it why people get so excited with every new even-more-scalable DB yet at the same time completely ignore what's happening with things like graph DBs or hybrid-document-graph DBs that seem so f cool! Also... why would you want to live WITHOUT ANY JOINS nowadays?! Unless the scale requirements actually prohibit it, and let's face it, 99% of what people are doing is not even close to "big data" on mode…
For me it's because there are very few databases (you can count them on one hand) that check the following boxes: * Document or SQL Storage * Integrated Full Text Search * Can transparently survive a node going down (load balancer or client driver support) * Highly consistent by default, or allow operation level quorum settings * DR options with minimal lost writes * Transaction support * Hosted * Affordable for smal…
We call it a data layer, not a database, because it's a higher-level document data model layered on top of Postgres (with pluggable data stores that can be added at runtime; we hope to support other backends such as Redis and Cassandra and maybe CockroachDB if it's a good fit) and Elasticsearch (also intended to be pluggable), similar to how TitanDB is implemented.
It supports transactions — atomic multi-document updates within a single data store that supports this — fine-grained CRDT-style document patching, update streaming, versioned schemas and a fine-grained permissions system. The query language isn't SQL, but our own relationship-oriented, vaguely GraphQL-like query language that allows querying on anything that Elasticsearch can express, as well as complex joins and aggregations. Since Elasticsearch is eventually consistent and all queries go through it, we aim to provide some consistency-tolerance semantics when a client does need strict consistency in combination with queries.
We're not quite ready to publish the code, but drop me line (email in profile) if you want to be notified when it becomes available.
Earlier quoted context omitted.
Check out MemSQL Community Edition which has these features
Thanks Eric, MemSQL is pretty awesome but I can't really begin to consider it when: 1. Backing up your data is somehow an Enterprise feature? 2. No pricing anywhere on the site, which usually means: 2.1. Sales calls. Nothing I hate more in this world than sales calls. 2.2. $$$$$$$ (which is fine, but I like to know roughly how much $$$$$ before 2.1.) As far as functional indices, I don't see that here: http://docs.me…
Earlier quoted context omitted.
> This is one of the most exciting DB's coming into the world, and I've had a lot of fun watching progress from the sidelines! I'm going to have to disagree. The German HyPer DBMS has a lot more interesting ideas. Cockroach is just distributed MVCC from the 1980s on top of a key/value store. MemSQL also has a new LLVM architecture written by the HipHop VM inventor that they poached from Facebook.
HyPer and MemSQL are in-memory databases. CockroachDB is not. This is a big difference. And according to HyPer home page, HyPer doesn't look distributed, which is another big difference.
Earlier quoted context omitted.
CockroachDB's replication protocol is based on Raft, which is not susceptible to split-brain. (Neither is Spanner, but Spanner requires specialized hardware for clock synchronization.) And contrary to your assertion, it allows consistent snapshots and transactions that cross shard boundaries. The rest of your comment ignores a couple decades or so of very extensive research into scalable distributed transactions. Des…
Raft isn't, but that is extremely different from whether an implementation of Raft is or isn't. Kyle Kingsbury's work shows this to be the case quite often - see http://jepsen.io/ . I have read the design document, and know how Spanner works. This isn't the first time I've asked about this, I had the 2nd highest upvoted comment on the initial CockroachDB announcement ( https://news.ycombinator.com/item?id=9660339 ) w…
Earlier quoted context omitted.
The "mouse" (computer hardware) has an equally bad name, and yet...
You think mice and cockroaches evoke the same emotions in the average human?
Calling a product a "mouse" must have seemed like a strange decision at the time. Now we don't think twice about it. My point is that people get accustomed to things over time.