Skip to content
Matt Pouttu-Clarke edited this page Jun 27, 2016 · 7 revisions

Bloklinx provides data versioning much like that provided by git to big data and fast data analytic systems. Bloklinx works best with large change sets rather than onesy twosey changes. If you are working with small change sets or require explicit locking, work with a relational database like MySql or Postgres rather than Bloklinx. That being said, Bloklinx provides:

  • Natural session-based change windowing
  • Idempotent point-in-session snapshot view throughout all historical changes
  • Branch and merge of snapshots
  • Automated conflict resolution where possible, fast alerting of conflicts requiring intervention
  • Versioning of structure as well as content
  • No requirement to specify "keys" for records (i.e. implicitly supports changing the "key" for the record while maintaining provenance)
  • Easy refresh of downstream aggregates, splits, transforms, and replicas via built-in change data model
  • Extremely efficient query and aggregation without any requirement for grouping by "key"
  • A NOOP code which allows smoke test of the system without effecting real data

Bloklinx provides this by applying concepts from blockchain and git, and requires only a shared file system to store metadata. Bloklinx has a strong bias toward Google's flatbuffers for storage, although other formats may be supported in the future.

Clone this wiki locally