FAQ

FAQ

Click on a question to see the answer. Open All / Close All

Does the TransLattice Application Platform actually provide both SQL functionality and scale-out capability?
TransLattice is built on the world’s first globally distributed relational database management system. TransLattice delivers the functional capabilities of traditional relational database management systems including ACID guarantees of SQL on building-block style nodes that can be deployed anywhere you require processing power to deliver your data where you need it, when you need it. Nodes can be either physical appliances or cloud instances.
How can TransLattice support ACID semantics across multiple physical locations?
The TransLattice Application Platform is built on the world’s first geographically distributable relational database management system. TransLattice enables concurrency and consistency with predominantly non-blocking, asynchronous messaging to present a single database instance spread across nodes located at multiple physical locations. Our Global Consensus Protocol and distributed query planner ensures that updates are applied consistently across the cluster and avoid collisions.
What happens if people on different nodes attempt to update the same information at the same time?
TransLattice’s Global Consensus Protocol determines the sequence in which transactions are committed to the database and how conflicts are resolved. This protocol can be augmented by user-defined policy to support common business practices. Multi-version Concurrency Control (MVCC) ensures that transactions see a consistent view of the database while allowing distributed parallelism.
What is the limit of a TransLattice cluster size?
A TransLattice cluster can scale to dozens of nodes as a single-instance database. With each additional node, the database scales incrementally so you can deploy only what you need, when you need it. When burst capacity is required, cloud instances can be added to the cluster to boost processing power in minutes.
If our workload increases, how can we scale the TransLattice system to provide additional capacity and performance?
Simply add one or more TAP appliances or cloud instances to your existing cluster and assign an IP address. You can add hundreds of nodes and your TransLattice cluster still appears to applications as a single database. As nodes are added to the cluster, data is automatically and intelligently spread across the nodes and workload is balanced across available resources.
What happens if we have a hardware failure, such as a failed drive or node?
TransLattice’s distributed, shared-nothing architecture was designed for high availability. If any component fails, the system continues to operate without any disruption. With TransLattice, ample redundancy is built into the system at all levels. Workloads are simply re-balanced across the remaining architecture and clients reconnect to another node. Self-healing occurs in the background to automatically restore the system to its original processing level without intervention.
What types of applications is the TransLattice Application Platform intended for?
TransLattice was created to improve the resiliency of traditional enterprise applications built on ANSI-SQL RDBMS platforms such as CRM, ERP, SCM suites and custom applications. The initial release of the platform supports Java EE applications.
How difficult is it to migrate applications to the TransLattice Application Platform?
TAP supports PostgreSQL syntax; Java applications that run on PostgreSQL will run unchanged on TAP. Applications written for Oracle should run on TAP with few, if any, changes. Applications written for other relational database management systems that do not make extensive use of proprietary constructs migrate to TAP easily.
How does TransLattice avoid latency problems commonly associated with data replication?
Replication and partitioning, in the traditional sense, are not used in Lattice Computing. Logical segments of data are placed only on nodes where they are needed either to provide necessary redundancy and business continuity or to satisfy business-processing requirements. TransLattice recognizes frequently accessed data and can spread it to additional nodes of the cluster improving response time and preventing bottlenecks. Because each piece of data is only replicated on a small number of nodes, latency issues are avoided.
How does TransLattice determine which data is placed on which nodes?
A number of factors control data placement. These include Redundancy Policies, Location Policies and actual usage. Redundancy Policies control the minimum number of copies and locations for each type of data stored. These policies help ensure business continuity in the event of component failure. For example, a Redundancy Policy might say store at least three copies of all data on at least two continents. Such a policy would ensure that business would not be disrupted in the event that all the nodes on one continent became unavailable due to a disaster. Location Policies ensure that business controls are enforced. For example, a Location Policy might indicate that all Personally Identifiable Information (PII) must remain in the country of origin, or that financial information cannot leave the continental U.S. As data is used, additional copies are placed where locating policies permit to improve performance. The most efficient storage plans are used, choosing nodes from which data is accessed often or nodes with greater network bandwidth.
How will your product increase productiveness and save time/money?
The TransLattice platform provides inherent resilience by design and redundancy levels can be specified by the customer via policy settings, thereby dramatically reducing the chance of a very expensive outage. (Ex. Virgin Blue, an Australian airline, estimates the cost of the outage they suffered last September that resulted in hundreds of canceled flights at $15–$20 million.) Deploying an application on the TransLattice platform can save up to 60% compared to a typical deployment due to the dramatically different architecture.