spanktar

When entering any questionable law enforcement situation (TSA, walking near a protest, traveling internationally) I always switch my phone to not use TouchID. Say what you will.

+1 for something along these lines to be available in all vendor's dev tools!

I tried to implement a system like this once, with the goal being to reduce the amount of equipment and clutter on the service counter, but ran into issues of trust. I learned very quickly that if you remove the cash from sight of the customer (even by turning around or having a cash register under the counter) you invite potential fraud from the cashier or the customer. The cashier is able to skim, or the customer to claim they gave a different amount if the money disappears, even briefly. I gave up on it and kept the standard "customer-facing register" setup.

Wait, you mean the millions, possibly billions spent already haven't done a thing? Shocking! And now you can pay (TSAPre) to bypass the security theater essentially proving that the whole thing is a massive sham. I'm all for security, but nobody can seem to define what that would actually look like, as opposed to what we have now.

Spanky from Crate.io here if there are any followup questions.

Have you checked out Crate.IO? https://crate.io/overview as an "SQL for Elasticsearch" option.

At least they didn't update the power port...again.

Image for the TGF-β pathway, in case you're into that kind of thing: https://www.qiagen.com/us/products/genes%20and%20pathways/pa...

Without violating your confidentiality, can you share what version of ES you experienced these failures with? I have also experienced this first hand, but since 0.9x and 1.0x a TON of work has been done on both OOM (one of the leading causes of split brain scenarios) and split-brain from network partitioning. As I mentioned below, all of these issues are being addressed in an open and transparent way, and while there's still work to be done, a non-trivial amount of progress has already been made. I hope you can share at least some about your experiences.

Lots of great questions here. Don't forget that you can also ask detailed questions in our Google Group: https://groups.google.com/forum/#!forum/crateio

True. There is an elected master node and you can configure a cluster to have master-only (non-data) nodes, data-only nodes (non-master eligible), or both. Even still, and even if you choose to set up a cluster this way, every node can perform the same functions, it's more a matter of what responsibility a node has. And even though there is a master node, that master can disappear without consequence, another will be elected in its stead. There is nothing really "special" about a master node.

Like Jodok says, we don't recommend this, but you could do it. What this would mean that if you destroy a container, you also destroy the data. This would cause your cluster to have to rebalance itself adding IOPs overhead.

When you map a volume into a container as suggested, the data can persist through a container restart/replacement. When the container is instantiated, the volume is read, the node checksums the shards it finds to make sure they're not stale. If so, they're brought up to date. By tuning the recovery settings you can avoid extraneous shard movement and therefore leverage containers as you would expect.

By shared-nothing, we mean that no node is special, no node is indispensable. Unlike other popular NoSQL databases, we don't have different classes of nodes. The persistent data is distributed across the cluster, and nodes communicate amongst each other about which data are where.

http://en.wikipedia.org/wiki/Shared_nothing_architecture

Yes, and while there are still cases (see the link @jodok supplied below) a ton of work was done in ES v1.4.x (which Crate uses) and even more issues were closed in ES v1.5 which we're working on supporting.

With the amount of attention and support this has received from both Crate and ES, coupled with the amount of progress that's been made against these issues, I don't think it's a fair to advise against using either as a source of truth.

That's part of it, but not the whole picture. For example, we mostly bypass the ES query engine and go directly to Lucene. Queries are not simply translated to ES query syntax. Also, we've done a lot more work than simply pasting an SQL layer over the top. We've built streaming BLOB support, a distributed SQL layer with real-time MapReduce, and a distributed aggregation engine that gives accurate results for aggregations rather than HLL estimates.

If you'd like we're happy to answer any questions in IRC or our Google Group: https://groups.google.com/forum/#!forum/crateio IRC Freenode #crate: irc://irc.freenode.net/crate @mention anyone with Voice

Crate is a database engine that uses Lucene for storage and leverages portions of Elastic for cluster management. It is a NoSQL storage engine that gives you an SQL API (via REST). It does not support JOINs yet but this work is well underway and we expect a release with JOINs soon. We have several customers migrating from MySQL without JOINs (either handling joins in the application layer, using arrays in columns, or denormalizing data). Transactions are not ACID, we fall into the eventually consistent realm. And finally, not all use cases require user/group security, in fact much of the current SQL usage falls into the single user category.

I also agree that our site is not as clear as it needs to be and we're working on it already.

I should have mentioned, the Crate.io (database) codebase is on GitHub: https://github.com/crate and this is what we're building: https://crate.io/overview/

Hi, Spanky from Crate.io here. We still maintain the PyPI portion of the site at https://crate.io/packages

As for crates.io, I guess their entitled to choose their own name & domain, but I admit it is confusing.

At Crate.IO, we've been playing around with deploying our clusters using Machine & Swarm, so this is pretty good use case: https://crate.io/blog/deploying-crate-with-docker-machine-sw...

Basically right now, you can't run two third party services at once, because they both need to wrap the Docker commands. Now you can use multiple services at once (Flocker, Weave, etc.) True that it's just a transforming proxy, but right now it's something that's lacking for the Docker community.

I think the real meat of this article is here:

"...strikes multiple targets, including cell walls...Since the lipid structures it attacks don’t evolve as quickly as frequently mutating proteins, it may take the bacteria longer than usual to develop a survival tactic."

Proteins change often and quickly, but basic cell structures may take longer or never adapt.

But I'm not a pathobiologist, I just play one on the Internet

Super excited to have won the Startup Battle! Crate is a distributed database that uses a SQL interface to access Lucene-based data. You could think of it as "SQL for Elasticsearch" if you must, but it's much more than that. Questions? Comments?