Posted by
Raj Bains on Tue, May 21, 2013 @ 04:33 AM
Clustrix has changed the way businesses scale transactions and run real-time analytics, but the benefits of Clustrix don’t stop there. Clustrix was engineered from the ground up to reinvent and dramatically improve the way SQL relational databases handle the demands of today’s high volume data workloads.
Our most recent advancement has been the release of Clustrix 5.0 on Amazon Web Services (AWS). For companies seeking scale and performance for terabytes of data, Clustrix is the only scale-out SQL database available on AWS that allows you to scale transactions and run real-time analytics on the same database.
Here are eight awesome things you can do with Clustrix 5.0 on AWS:
1. Get easy database scale
Set up your Clustrix database with just a few clicks, and simply add nodes as your database needs to grow. No downtime, no code changes, and no configuration – just plug and play.
2. Scale transactions
When you have large datasets 100GB+ to terabytes and need to serve more queries than a single machine can support, Clustrix on AWS is here for you. One customer of ours used six Clustrix nodes to run 40k+ TPS of real workloads with a mix of simple and complex transactions.
Read this whitepaper to see how Clustrix enabled Massive Media’s site Twoo to go from concept to launch in less than six months, and from zero to over four million users in less than one year.
3. Run fast, real-time analytics
Clustrix uses Massively Parallel Processing (MPP) that uses multiple servers and multiple cores within each server to process OLAP queries. Our multi-version concurrency control ensures that analytic queries never interfere with writes, which means you can run real-time analytics and transactions at the same time and save on the cost of deployment and maintenance of a separate analytic database.
This whitepaper delves more into Clustrix’s performance on Amazon Web Services.
Adscience, an online ad broker, can now run algorithms that leverage five days of click history within a 120-millisecond window on Clustrix. Watch the webinar to learn more.
4. Simplify operations
Unlike shortsighted strategies such as database sharding, Clustrix does not have complex write master and read slave setup. When you lose a node, you simply add another node—you don’t have to promote or set up additional slaves. In case of load imbalance, the Clustrix rebalancer takes care of it.
5. Set up disaster recovery
Clustrix lets you set up replications across geographies for disaster recovery, and you can set it up as either master/slave or multi-master. Clustrix also supports fast parallel backup, which allows you to perform fast backup irrespective of the number of nodes.
6. Achieve high availability
Clustrix maintains multiple copies of each piece of data within a cluster. So, if you happen to lose a node, the cluster stays available and the lost copies are simply regenerated. Clustrix also stays available through node additions.
7. Develop with agility
Clustrix provides online schema changes, meaning you can change your schema, like add columns, while your database is running. This means you can iteratively develop your database scheme and add features without downtime.
Check out this forum post for more information.
8. Never hit a performance limit
If you want even more performance than Clustrix on AWS, than it’s simple to set up a direct connect to the Clustrix appliance within a cloud environment. This gives you a vertically integrated solution for optimal performance using a fast InfiniBand interconnect. If you want to move to the private cloud, Clustrix has multiple options for that as well.
Got questions? Use the comments section below.
By Matt White, Lead Software Developer
A user on StackExchange recently asked the question, “Why can't RDBMs cluster the way NoSQL does?” The question received several good answers, one of which essentially amounted to ‘ACID is hard in a shared-nothing system,’ and then proceeded to enumerate what was hard about it. While there’s no doubt that maintaining ACID properties in a clustered database can have its challenges, it’s far from impossible. This blog entry is culled from a response I gave in that StackExchange thread and describes how Clustrix maintains ACID in a clustered environment.
Clustrix offers a clustered, shared-nothing scalable database software delivered either as an appliance or an AWS AMI. The nodes of a cluster are homogeneous peers, connected by a relatively high-speed network (Infiniband for the appliance and Ethernet for AWS). Relational data is hash distributed across the nodes on a per-index basis in chunks we call ‘slices.’ Each slice will have two or more replicas spread throughout the cluster for durability in the event of a node or disk failure. Clients connect to any node in the cluster to issue queries using the MySQL wire protocol.
So how do we approach maintaining ACID properties and what tradeoffs do we make to maintain those properties? The original discussion attempted to break apart the individual ACID properties because NoSQL solutions usually involve relaxing one or more of them. It’s a bit unnatural to think about ACID as individual properties because they dovetail together to provide what most of us think about as a relational database, but since that’s how the original discussion went, so will this blog entry.
Atomicity
Clustrix uses a combination of two-phase locking and MVCC to ensure atomicity, which increases the amount of messaging between the nodes participating in a transaction and increases load on those nodes to process the commit protocol. This is part of the overhead for having a distributed system and would limit scalability if every node participated in every transaction. Fortunately for Clustrix, that’s not the case.
Clustrix uses the Paxos consistency protocol that requires participants of a transaction to include the originating node, three logging nodes, and the nodes where data is stored (a single node may serve multiple functions in a given transaction). This means the communication overhead for full table scans is quite high, whereas the simple point selects and updates that make up the majority of applications have a constant overhead. OLAP transactions compute partial aggregates on the node where the data is located and therefore don’t suffer from high overhead. Range operations without aggregates are expensive, and applications that make heavy use of them are probably not well suited to Clustrix.
Consistency
When we talk about consistency, we’re usually referring to ensuring that relational constraints such as foreign keys are enforced properly. Clustrix implements foreign keys as triggers, which are evaluated at commit time. Big range UPDATE and DELETE operations can hurt our performance due to locking (and the aforementioned communication overhead), but these operations are not common in most applications.
The other part of consistency in a distributed system is maintaining a quorum via the Paxos Consensus Protocol, which ensures that only clusters with the majority of the known nodes are able to take writes. In the event of multiple node failures, it’s possible for a cluster to have quorum and still have missing data if all replicas for a slice are unreachable; transactions that access these slices will fail so long as this condition exists.
Isolation
Clustrix provides MVCC isolation at the container level. Our atomicity guarantees that all applicable replicas receive a particular write before we report the transaction committed. This, for the most part, reduces the isolation problem to what you'd have in the non-clustered case.
Durability
The durability guarantee provided by Clustrix includes normal write ahead logging (WAL) as well as replication of relational data within the cluster. The appliance version of the Clustrix SQL relational database has an NVRAM card for storing the WAL, whereas a lot of single instance databases will improve the performance of their WALs by checkpointing at intervals instead of at each commit. This approach is problematic in a distributed system because it makes 'replay to where?' a complicated question. We sidestep this in the appliance by providing a hard durability guarantee.
So What are the Trade-Offs?
What does Clustrix give up to be a distributed system? The answer to this question depends pretty heavily on the application and its implementation details. For example, a primarily OLTP workload may have additional single query latency even as the cluster's throughput scales nicely. That extra latency could go unnoticed or be a real deal breaker, depending on the application.
The simplest non-trivial queries on Clustrix, point selects, execute in three program fragments requiring two communication hops. On the appliance, this communication is via Infiniband (7us latency), so the majority of the induced latency will be marshaling messages to send. In AWS, the inter-node latency is much higher – in the 5-600us range – and therefore plays a much bigger role (1ms for communication latency alone). OLAP queries are much harder to estimate because Clustrix’s parallelism serves to reduce latency of these queries while the communication overhead from join operations increases it. In general, our customers find that their OLAP queries run with significantly less latency on Clustrix, but it’s hard to quantify that difference.
Got comments or questions? Please leave your remarks below.
Read the full article in WSJ here.
Last week, Clustrix announced that it raised $16.5M in its latest Series C funding round. The Wall Street Journal declared that “tech watchers once considered the database market pretty stagnant, at least in terms of new technology and new entrants. Suddenly it is anything but that, with Clustrix a prime example.”
The investors contributing to this latest funding round include Sequoia Capital, U.S. Venture Partners, ATA Ventures, and Don Listwin, a past Cisco executive and CEO of Openwave Systems. This round raises Clustrix’s total capital raised to date to $46.5 million.
Robin Purohit, Clustrix CEO, has stated that Clustrix will use this funding to ramp the sales and marketing of the Clustrix software, but will continue to focus on selling appliances as well.
Read the full WSJ article here.
Free whitepaper – download here.
Since 2010, real-time bidding has tripled its share of display advertising, and in 2013, nearly one in five display dollars will go to real-time bidding.
What does this mean for the world of online advertising? For starters, the market is growing faster, more competitive, and more innovative every day. It also means the success of the industry depends on a database’s ability to run high speed, real-time analytics while simultaneously running transactions.
Real-Time Makes All the Difference in Advertising Analytics
More of advertising spend is shifting to real-time bidding on exchanges, demand side platforms, agency trading desks, and retargeting—meaning advertisers require real-time bidding tools that can process massive data sets and calculate bids against billions of impressions in real-time.
Advertisers also need to run reports in real-time to see how their algorithmic strategies are doing in order to potentially reallocate funds. Access to real-time analytics enables maximum use of data and optimal pricing.
Unfortunately, most analytics platforms are built on databases that are unable to keep up with transaction and analytic demand, and end up being the bottleneck to success. Legacy databases are unable to scale and accommodate more detailed and complicated analytics, thereby limiting the feature set
and speed of innovation.
Challenges to Running Real-Time Advertising Analytics
The move toward real-time bidding and targeting presents several technical challenges for online advertisers.
First, the bid for an impression needs to be made in an extremely small window of about 100 milliseconds. And, within this small window, advertisers need to run increasingly complex analyses to ascertain the suitability and the right pricing for a bid followed by the selection of a customized ad.
Demand-side platforms (DSPs) also provide self-serve models for advertisers to run and manage their own campaigns. Key requirements for a successful interface are the ability to generate real-time performance reports, create successful strategies, and allocate funds toward them.
So if traditional legacy SQL databases aren’t up for these challenges—what can advertisers do?
Finding the Right Solution for Real-Time Advertising Analytics
The right database needs to fulfill the needs of a basic scalable primary database as well as have a strong analytics story. First, any scalable primary databases needs to provide:
- A scale-out architecture – As your data load increases,
you must be able to simply drop in extra nodes to handle it. You shouldn’t have to change your application, and data and queries should auto-distribute.
- SQL and ACID – Since it’s your primary database, it should provide the guarantees to ensure data is safe and consistent.
- Fault tolerance – You need your data to be available despite node failures and geographic region outages.
And if you’re thinking ahead, you know you also need to run analytics in real-time, meaning your ideal database should provide:
- Multiversion concurrency control (MVCC) – MVCC ensures analytic queries and writes don’t interfere with each other. The analytic query reads a snapshot of the world as it came in, and the write queries can then write newer versions. The older versions are garbage that gets collected when it’s no longer needed.
- Massively parallel processing (MPP) – If you want performance that can scale, you need a database that can use multiple nodes and multiple cores on each node, in parallel, to accelerate your analytic queries.
Clustrix is the only database with all the features that online advertisers need to find success in the increasingly competitive online advertising world. Just look at how Clustrix helped Adscience, an online ad broker agency, leverage more historical data to select the right bid and increase revenue potential by five times.
For even more information on how Clustrix dramatically improves real-time analytics for online advertisers, download our free whitepaper, “Accelerating Real-Time Analytics for Advertising.”
Where: Austin, TX
Who Should Attend: Developers, DevOps, and Database Administrators
Join us at our lunch & learn event this Wednesday, May 8 - Register here.
Whether it’s a web scale application, real-time analytics, or setting up a private cloud database, you will almost certainly be faced with identifying the right distributed database platform for your company. Legacy databases will be around for a while, but modern apps and cloud architectures demand a scale-out database solution.
Get it right, and you set your company up for years. Get it wrong, and it’ll be time to update the resume.
In this session, Sergei Tsarev, CTO and Founder of Clustrix, will help you understand how to evaluate scale-out (i.e. distributed) databases. You’ll learn:
- How to understand the architectural trade offs each database vendor makes
- How to map application workloads to core uses cases of different distributed databases
- What to consider beyond performance -- in operations, availability, and management
- How to test a distributed database to know if it will work for you
Agenda
12:30–12:45 Check in and welcome
12:45–1:15 Talk: How To Evaluate A Distributed Database
1:15–1:30 Discussion and Q&A
Location
NXNW Restaurant and Brewery – Pavilion Room
10010 N. Capital of Texas Hwy
Austin, TX 78759
Lunch and drinks will be served.
Register here. Once we receive your registration, we’ll follow up to confirm.
Speaker
Sergei Tsarev, CTO
Sergei led the Internet Operations Systems Infrastructure team at AOL, designing large-scale monitoring and configuration management systems. Sergei's accomplishments include developing the Simple Time-series Database (STDB), a high performance data storage engine for operational monitoring metrics. STDB uses commodity hardware to linearly scale to hundreds of thousands of writes per second. It has become the standard storage engine for network and host monitoring data for all of AOL, replacing traditional high-end database infrastructure.
Sergei earned a Bachelor of Science degree in Computer Science from University of Maryland, College Park.
Announcing our newest release, Clustrix 5.0. Clustrix 5.0 is for data-driven businesses that require blazingly fast real-time analytics on operational data. Clustrix 5.0 is a row-based SQL database designed to bring Massively Parallel Processing (MPP) to analytic queries on operational data. The same near-linear scalability Clustrix has previously brought to OLTP workloads is now achievable for analytics. Simply add nodes to scale the system and cut the time to process analytic queries. This scale-out analytics is achieved with innovative distributed aggregates and OLAP fan-out technologies, where multiple cores across multiple nodes work in parallel on analytic queries. Analytic query performance can improve by 25x, and up to 1000x in some cases.
In order to demonstrate how Clustrix scales performance, we've designed a series of tests that demonstrate how the system performs on different workloads with additional nodes. While Clustrix has evaluated the system across many different benchmarks (e.g. TPC-C, etc.), the tests are designed to address the core problems present in each workload while maintaining enough simplicity so that others may reproduce our results.
Read the full test methodology and analysis here.
It’s been a busy few months at Clustrix, but it goes by fast when you’re doing something that no transactional database has done before. And that’s what we’ve done with Clustrix 5.0 on Amazon Web Services (AWS) Marketplace.
What’s so exciting about Clustrix 5.0? A few things—not only is Clustrix 5.0 available for both free developer testing and full production use on AWS Marketplace, but it also now brings real real-time analytics to our already powerful transactional system. Try Clustrix on AWS today.
What is Real Real-Time Analytics?
Gartner has said for years that there is no such thing as "real-time" analytics. Due to the limitations of traditional legacy databases, businesses had to either run batch reports during off-peak hours or move data to a separate system for analysis. This was problematic for several reasons—it was expensive, complicated, and, of course, was not real-time. According to Gartner, true real-time analytics has the potential to transform business. We agree.
We’ve worked with our customers over the last 12 months to build real-time analytics processing on our proven OLTP system. Our customers want what many data-driven businesses want—operational intelligence to make business decisions in real-time. This means running blazingly fast real-time analytics and high-scale transactions on operational data at the same time. That is what we’ve done with Clustrix 5.0.
Improve Analytic Query Processing By Up to 1000X on Clustrix 5.0
Clustrix 5.0 offers some very specific analytics processing technologies that can improve real-time analytic query performance by up to 1000X.
The first is what we call OLAP Fanout that allows multiple cores across multiple nodes to work in parallel on analytic queries. This acts like a multiplier effect on Clustrix’s unique ability to break complex queries into query fragments. Now, each fragment can be distributed down to the core level to be operated on in parallel. Another key new capability is Distributed Aggregates that lets nodes work in parallel to accelerate aggregate queries.
Combined with other key elements, like MVCC so writes never interfere with reads, Clustrix 5.0 is the first and only row-based SQL database to bring Massively Parallel Processing to analytic queries on operational data. Read more in our press release.
Clustrix 5.0 Now on AWS
Clustrix 5.0 software running and available on an hourly basis on AWS is a major milestone for our company, and I’m excited for what’s now possible.
With our free version for developers, it’s easier than ever for someone to kick the Clustrix tires. And for as low as $0.12/hour per node, anyone can try our scale-out version—fire it up when you need it and scale it back when you don’t. Clustrix is available in all AWS availability zones.
More and more companies are building and growing their applications on AWS, and now these companies can grow on Clustrix and enjoy fault tolerance, high-scale transactions, real-time analytics, and a reasonable price that grows with you. And while they may worry about what features to build to become the next Facebook, they’ll never have to worry about whether their database will scale when they hit it big.
Try Clustrix 5.0 on AWS today and let us know what you think.
Thursday, April 25, 2013 11:00 AM PST / 2:00 PM EST
Register now.
Ruby on Rails with a single MySQL server is one of the fastest ways to create and deploy a world-class web app. Scaling that application is another story. Since you can add web capacity easily, the ability to scale a modern Ruby on Rails application rests solely upon the scalability of the database.
Single instance, scale-up databases simply don’t make sense in a Web 2.0 world. And non-relational databases require you to sacrifice too much – transactional integrity, consistency, durability, and security.
In this webinar, learn the results of a benchmark that compared the performance of Ruby on Rails using MySQL, and Clustrix, a scale-out SQL database engineered for the cloud.
Some items covered will include:
- How database performance (measured as transactions per second) is impacted by increasing concurrency (measured by total threads)
- How to quickly and easily achieve breakthrough scalability for Ruby with MySQL
- How to reduce the costs associated with scaling Rails
- How to retain all the powerful functionality of Rails, even while scaling linearly
As a special bonus, all webinar attendees will receive the whitepaper, “Ruby on Rails Database Benchmark.”
Register now.
Speakers:
Robert Taylor, Strategic Technical Account Manager, Blue Box Group
Robert Taylor has spent many years in the tech industry in positions ranging from Lead Developer to Sr. Systems Engineer to Lead Platform Architect. Communicating technical expertise to serve customers is his passion.
Clayton Cole, Applications Engineer, Clustrix, Inc.
Clayton strives to understand and address the challenges customers face as they transition their unique environments over to using a scalable Clustrix database solution. For several months he worked to benchmark the performance of both Clustrix and MySQL using Ruby on Rails.
SQL query optimization is well known to be a difficult problem. At Clustrix, when we began to architect a new type of distributed database, we knew the query optimizer would be critical to system performance. The distributed nature of Clustrix allows us to produce better execution plans than non-distributed systems, but it also adds more complexity to the optimizer as it now has to reason about how data is distributed in the cluster.
The Clustrix query optimizer is called Sierra, which is a cost-driven, extensible optimizer that is a never-ending project. It is modeled off of the Cascades framework that is also used by MS SQL Server and Tandem's NonStop SQL product.
Sierra works with a simple query:
CREATE TABLE `employees` (
`employee_id` int(11) NOT NULL,
`name` varchar(256) CHARACTER SET utf8,
`salary` int(11) DEFAULT NULL,
PRIMARY KEY (`employee_id`),
KEY `idx_salary` (`salary`)
)
select * from employees where salary < 50000;
This is the classic problem of index seek vs. table scan. We could either:
A) Scan all the rows of the base representation and filter rows that fit the predicate, "salary < 50000"
or
B) Scan only the rows that fit the predicate from the idx_salary representation and then lookup the missing columns from the base representation (the missing column being `name`).
On Clustrix, plan B is nothing more than a join of the two representations with a primary key equality as the join predicate. Sierra's high-level steps are:
- Take the original query and expand the search space to include plan A and B via transformation rules
- Find the cardinality of the table and calculate the selectivity of the predicate
- Cost both plans with this statistical information
- Choose the cheaper plan
Clustrix performs step two by querying per-representation statistics. Selectivity is a critical component of a query optimizer’s ability to find a good plan. Clustrix built a statistics-capturing framework that updates on the fly without interrupting the throughput of the system. More on this in a future post.
In step three, Sierra costs the plan using a combination of I/O, CPU usage, and latency. Remember that Clustrix is distributed, so total CPU usage and latency are not proportional. Cost is a tricky measure; if we ignore latency in the cost factor we can maximize the throughput of the system under heavy load. If we use latency as the cost factor, we will provide more responsive queries when the system is not loaded. A mixture seems best in practice, but we are continuing to tune this metric and have placed knobs in the system so we can adjust to specific customers.
Let’s take a closer look at steps three and four. Here are the two plans with the same predicate. We can compare the costs of the plans by forcing the planner to use an index via a hint.
Plan A
clustrix>explain select * from employees where salary < 50000;
+------------------------------------------------------+-----------+-----------+
| Operation | Est. Cost | Est. Rows |
+------------------------------------------------------+-----------+-----------+
| filter (1.salary < param(0)) | 31003.90 | 12442.00 |
| index_scan 1 := employees.__idx_employees__PRIMARY | 30003.90 | 50000.00 |
+------------------------------------------------------+-----------+-----------+
2 rows in set (0.00 sec)
Plan B
clustrix>explain select * from employees use index (idx_salary) where salary < 50000;
+-----------------------------------------------------------------------------------+-----------+-----------+
| Operation | Est. Cost | Est. Rows |
+-----------------------------------------------------------------------------------+-----------+-----------+
| nljoin | 63458.10 | 12442.00 |
| index_scan 1 := employees.idx_salary, salary < param(0) | 7469.10 | 12442.00 |
| index_scan 1 := employees.__idx_employees__PRIMARY, employee_id = 1.employee_id | 4.50 | 1.00 |
+-----------------------------------------------------------------------------------+-----------+-----------+
3 rows in set (0.00 sec)
For this predicate, the optimizer determines plan A costs 31K and plan B costs 63K, and decides to choose plan A. This is because the predicate wasn't all that selective, it was 12442/50000 ~= 25%. In the execution of plan B, when the predicate is not that selective, a lot of rows will be joined from the idx_salary representation to the base representation. This is pretty costly compared to plan A, where we just scan the base representation and filter rows before completing. Check out the blog post Scaling Distributed Joins by Sergei Tsarev, our Co-Founder and CTO, to learn more about how Clustrix executes joins.
Let’s see what happens with a more selective predicate, "salary < 41000." Note that we have to use "use index" on plan A instead of plan B this time around:
Plan A
clustrix>explain select * from employees use index (primary) where salary < 41000;
+------------------------------------------------------+-----------+-----------+
| Operation | Est. Cost | Est. Rows |
+------------------------------------------------------+-----------+-----------+
| filter (1.salary < param(0)) | 31003.90 | 1336.00 |
| index_scan 1 := employees.__idx_employees__PRIMARY | 30003.90 | 50000.00 |
+------------------------------------------------------+-----------+-----------+
2 rows in set (0.00 sec)
Plan B
clustrix>explain select * from employees where salary < 41000;
+-----------------------------------------------------------------------------------+-----------+-----------+
| Operation | Est. Cost | Est. Rows |
+-----------------------------------------------------------------------------------+-----------+-----------+
| nljoin | 6817.50 | 1336.00 |
| index_scan 1 := employees.idx_salary, salary < param(0) | 805.50 | 1336.00 |
| index_scan 1 := employees.__idx_employees__PRIMARY, employee_id = 1.employee_id | 4.50 | 1.00 |
+-----------------------------------------------------------------------------------+-----------+-----------+
3 rows in set (0.00 sec)
This one is quite a bit more selective – it’s 1336/50000 ~= 2%. In this case, plan A costs 31K and plan B costs 6.8K, so the planner chooses plan B. In effect, Sierra realizes that not as many rows need to be joined from the two representations with this predicate and decides that the plan B join is cheaper.
Though Sierra is a powerful query optimizer, it’s not complete and never will be. This is why Clustrix decided on an extensible framework. In fact, Clustrix just recently introduced distributed aggregates to the system with minimal disturbance to the optimizer.
We invite you to request future blog topics about the query optimizer and/or compiler in the comments section below. We always welcome any and all of your comments and suggestions.
Join Clustrix at the Percona Live MySQL Conference and Expo on April 22-25, 2013 in Santa Clara, CA. Register here today.
And on April 24th, our very own Raj Bains, lead Product Architect, will host a presentation titled “Accelerating Real-Time Analytics with Clustrix.”
Register for the Percona Live MySQL Conference and Expo 2013 today.
Accelerating Real-Time Analytics with Clustrix, Raj Bains, 3:30 – 4:20 PM
Session Abstract:
Businesses that can make superior decisions in real-time are going to beat their competition. This is the primary challenge and opportunity of analytics. A great example of this is the online advertising market, where companies must choose and serve the best ads in milliseconds. This requires requires running analytics on the latest data in your primary database, while it's running transactions.
Clustrix distributed SQL database is known for linear scaling of transactions. Over the last year, we have built Massively Parallel Processing (MPP) for analytic queries, making Clustrix the only row-based SQL database with this capability. This brings the same linear scalability to analytics, allowing you to speed up analytic queries simply by adding nodes.
In this session, you will explore innovations being driven by the capabilities of real-time analytics, new deployment options possible with DBaaS and AWS, and the evolving SQL and NewSQL database landscape.
About the Speaker:
Raj is the lead Product Architect at Clustrix, focusing on product management and database engineering. Before Clustrix, he led the team and co-architected Financial Contract Definition Language, VM, and compiler at RMS. His background includes high performance computing, languages, and compilers at NVIDIA and Microsoft.
Percona Live Conference Details:
Date: April 22-25, 2013
Clustrix booth #304
Location:
Santa Clara Convention Center
5001 Great America Pkwy
Santa Clara, CA 95054
About Percona Live:
The Percona Live MySQL Conference and Expo is the premiere event for the rich and diverse MySQL ecosystem. It is the place to be for the open-source community, as well as the business marketplace within which MySQL thrives.