Tag Archives: SQL

(Excerpt from original post on the Taneja Group News Blog)

Recently we posted about GridGain contributing their core in-memory solution to the Apache Ignite project. While this is still incubating, it’s clear that this was a good move for GridGrain, and a win for the big data/BI community in general. Today Apache Ignite drops its v1.0 release candidate with some new features added in like built-in support for jCache and an autoloader to help migrate data and schema in from existing SQL databases (e.g. Oracle, MySQL, Postgres, DB2, Microsoft SQL, etc.).

(Excerpt from original post on the Taneja Group News Blog)

While the focus in databases recently has been on exciting NoSQL variants designed to tackle big data challenges or build transformational web scale apps, most enterprise applications still have mandatory requirements for transactional (ACID) properties keeping them tied to traditional relational database architectures. However, businesses are feeling pressured to evolve their transactional database solutions to enable highly available, “local” application access to globally consistent data.

Global IT shops face a big challenge in distributing relational data, as most approaches to-date have large implementation and operational overhead costs, and often involve serious trade-offs between local access and global consistency. Adding to the burden, local governments might have laws about ensuring data “location” compliance that absolutely must be met.

TransLattice started out delivering an appliance “platform” for distributed business computing. Due to popular demand, they’ve unhinged the database and launched that as its own solution called the TransLattice Elastic Database, or TED for short. Although calling your database TED seems a bit informal, the underlying implementation based on PostgreSQL is anything but. TED’s fully ACID/SQL relational implementation is designed to be logically and geographically distributed, providing policy-driven controls for each table’s replication. Transactions are automatically brokered and routed on the client side to ensure local performance and high availability, with a distributed commit algorithm on the backend to ensure global consistency. When nodes become unavailable, they get routed around, and when back online, automatically get updated.

TED database nodes can be TransLattice appliances, virtual machines, cloud based instances, or even all of them at once as access, availability, and performance needs dictate. TED nodes can be launched in Amazon EC2 for instance. Nodes can be added to the database dynamically, and data will automatically get distributed according to policy or performance needs.

The best part is that SQL applications don’t have to be modified or become aware that TED isn’t just the same old local SQL database. Since it drops in, scales easily and cost-effectively, and instantly increases global reach and availability, we think TED will go far.

Today at #snyc18 learning about the latest in #serverless. Opportunity is huge (iRobot is 100% serverless and loving it @ben11kehoe ), but not a panacea, lots of work to do to build up full production applications yet according to Kelsey Hightower (google) @kelseyhightower .