NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Boundary: All content tagged as Boundary in NoSQL databases and polyglot persistence

Boundary for Splunk app for correlating alerts

Alex Williams for TechCrunch:

Boundary‘s application performance monitoring technology is now integrated into Splunk‘s enterprise platform, providing a window into apps that increasingly are distributed across cloud and on-premise virtualized environments.

At first I thought this means Boundary will use Splunk as the backend for the data. But Boundary is a service so that’s not the case. Plus Splunk can already be used for network management and monitoring.

According to the post, “Splunk real-time alerts are tagged as annotations in Boundary’s time-series graphs. Customers can then correlate alerts against application flow and performance data.” So basically this is monitoring your monitoring system, right?

Original title and link: Boundary for Splunk app for correlating alerts (NoSQL database©myNoSQL)


Kobayashi: Historical Data Store with Riak

Speaking about networks, the company monitoring networks, Boundary, is investigating an issue with their historical data storage solution built on top of Riak:

Kobayashi is the name we’ve bestowed upon a new historical data store for streaming data yet to be integrated into the Boundary stack. Every few seconds, a small chunk of the most recent data for each “stream” is remitted to kobayashi for longer-term storage. There are roughly 15-20 of these streams per customer to cover the necessary dimensionality and aggregation periods required by the Boundary dashboard. Kobayashi runs on 9 nodes paired with a riak cluster running on those same 9 nodes.

These days, everytime I’m seeing an investigative monitoring dashboard, I’m thinking of Brendan Gregg’s great system visualizations.

Original title and link: Kobayashi: Historical Data Store with Riak (NoSQL database©myNoSQL)


Flake: An Erlang Decentralized, K-Ordered Unique ID Generator by Boundary

After posting about the proposal of adding a 128-bit K-Order unique id generator to Redis, I’ve realized I haven’t linked to Boundary’s post about Flake, their decentralized k-ordered unique id generator project:

All that is required to construct such an id is a monotonically increasing clock and a location 3. K-ordering dictates that the most-significant bits of the id be the timestamp. UUID-1 contains this information, but arranges the pieces in such a way that k-ordering is lost. Still other schemes offer k-ordering with either a questionable representation of ‘location’ or one that requires coordination among nodes.

Original title and link: Flake: An Erlang Decentralized, K-Ordered Unique ID Generator by Boundary (NoSQL database©myNoSQL)


Redis: Adding a 128-Bit K-Ordered Unique Id Generator

Interesting pull request submitted to Redis by Pierre-Yves Ritschard:

This is similar to what snowflake and the recent boundary solution do, but it makes sense to use redis for that type of use cases for people wanting a simple way to get incremental ids in distributed systems without an additional daemon requirement.

Snoflake is the network service for generating unique ID numbers at high scale used (and open sourced) by Twitter. Flake is an Erlang decentralized, k-ordered id generation service open sourced by Boundary.

Original title and link: Redis: Adding a 128-Bit K-Ordered Unique Id Generator (NoSQL database©myNoSQL)