Distributing Data The Aerospike Way

3,076 views

Published on

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,076
On SlideShare
0
From Embeds
0
Number of Embeds
31
Actions
Shares
0
Downloads
124
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • Welcome to distributing data the Aerospike way. This is an introductory presentation on the basics of how data can be parceled out in a distributed database. There are many ways to do this and we will be covering the plusses and minuses are for each.This is a pretty dry concept, so to make it a LITTLE more entertaining, we have an alternative, less dry title to this. Which is…
  • You may ask: “So why this alternate title?” As you take a look at the picture there may not seem to be much similarity between the two. But this is a situation most, if not all, of us have been through and there are some real similarities.
  • So let’s think about how you might do this on a small scale. Assume there are only 20 registrants.You would have a single table and give each person their registration package. This includes information specific to him/her. They will have their own class schedule and of course name tag.So what happens as the conference attendance grows. If you reach the point were there are thousand of registrants? How do you scale up?
  • We have all been in lines and seen the impact that the system uses. One way is to simply scale up the hardware on your single server. Another is to distribute the load. There are a number of ways to do this.Let’s start by taking a look at vertical scaling.
  • Vertical scaling has the virtue of being relatively simple. By making full use of the best hardware, you can handle more transactions.Because you are still dealing with a single server, you don’t have any problems with questions like:How do you distribute and map the data to different registration desks?What happens if two registrants check in at different booths?However, these benefits only work to some level. After that the minuses of this strategy become an issue.
  • Generally, upgrading a single server is simple. But the added costs in hardware can be considerable. A 64 core server is not cheap. Everyone does what they can to keep a monolithic database up. This includesRedundant power suppliesSometimes independent power sourcesRAID diskRedundant network connectionsBut even with this, servers may still go down. In some cases this is intentional, like for maintenance and upgrades. How many of up have tried to pay a bill online on Saturday night and found that the database is down?Even with all this, you may find that the business requirements still go beyond what you can do on a single server.So let’s look at what horizontal scaling offers.
  • Horizontal scaling means that the load and data will be distributed among many servers.There are several different strategies for this, along with different spins on each. If you are thinking about using a distributed database, there are a series of things you should look for.
  • Horizontal scaling can provide many benefits. Let’s take a look at some of the major features.This might seem odd, but first, you want features that prevent you from having to think about having a distributed database.
  • Simple sharding is based on distributing data according to simple patterns, like grouping people by last name.Hashed sharding is similar, but uses a computer algorithm to hash the key.Master-slave means that there is a master that helps determine what data goes where. The master controls how the data is distributed and must be consulted when accessing the data again.
  • The cluster
  • Horizontal scaling can provide many benefits. Let’s take a look at some of the major features.This might seem odd, but first, you want features that prevent you from having to think about having a distributed database.
  • How do have long running task (data re-balancing and back-up) and also doing short term transaction – do not starve – real time prioritization – while still keep short term with SLAs.Shared nothing:Allows upgrading of software in a rolling way (releases are backwardly compatible)Robust way of building cluster db systemsEach of our cluster notes is identicalBunch of nodes and bunch of clients.Even though node is identical – received/send data rebalancing, needs to second or third copy of data, as you add nodes will share proportional part of the dataMakes systems operations much simpler.Clusters are tightly coupled – nodes are close to each other - millisecondClusters are self configuring.Multicast (cloud we use mesh).Everything is synchronus within a cluster.Remote clusters are asynchronous.
  • Distributing Data The Aerospike Way

    1. 1. DISTRIBUTING DATA THE AEROSPIKE WAY Young Paik Director, Sales Engineering Aerospike young@aerospike.com July 24, 2013
    2. 2. …OR Why Is This Line Taking So Long? © 2013 Aerospike. All rights reserved. Pg. 2
    3. 3. A Database Is Like A Conference Registration Line ➤ The goal is to get as many people through the line as quickly as possible. ➤ Registrants must get their own registration package, not just anyone’s. © 2013 Aerospike. All rights reserved. Pg. 3
    4. 4. Scaling Throughput All databases (and registration systems) have limits to performance. The real question is how do you go beyond your current limits. There are two basic strategies: ➤ Vertical scaling – upgrade single server ➤ Horizontal scaling – distribute to multiple servers © 2013 Aerospike. All rights reserved. Pg. 4
    5. 5. Vertical Scaling Vertical scaling means that if a small server can handle some traffic … a big one can handle more. This is true … to a point. © 2013 Aerospike. All rights reserved. Pg. 5
    6. 6. What’s Wrong With Vertical Scaling? ➤ Expensive ➤ Still need to deal with failover.  What happens if your DB goes down?  What happens if you need to upgrade? ➤ May still not meet the storage/speed requirements ➤ Still a single point of failure © 2013 Aerospike. All rights reserved. Pg. 6
    7. 7. Horizontal Scaling Horizontal Scaling means that in some way the load will be distributed among many servers. © 2013 Aerospike. All rights reserved. Pg. 7
    8. 8. What Do You Want From Horizontal Scaling? ➤ Hide the complexity of distribution. ➤ Linear scalability. ➤ Better service availability. ➤ Deal with meteor strike on your data center. © 2013 Aerospike. All rights reserved. Pg. 8
    9. 9. Different Distribution Models Distributed databases will place different data on different nodes. Some common methods: ➤ Simple sharding ➤ Hashed sharding ➤ Master-slave ➤ Smart partitioning © 2013 Aerospike. All rights reserved. Pg. 9
    10. 10. Simple Sharding © 2013 Aerospike. All rights reserved. Pg. 10
    11. 11. Simple Sharding Clients know which node has the data. © 2013 Aerospike. All rights reserved. Pg. 11
    12. 12. Simple Sharding What happens if a node fails? © 2013 Aerospike. All rights reserved. Pg. 12
    13. 13. Simple Sharding Pros Cons + Easy to set up. Clients are written with a knowledge of how the data is distributed. + Servers aren’t coordinated, so no intra-cluster communication is necessary. - May lead to imbalance and hot nodes - If a node fails, the data on that node is unavailable. - Adding new nodes requires reconfiguration on the clients and re- shuffling of data on the server, resulting in service down time. - Replication must be handled separately. © 2013 Aerospike. All rights reserved. Pg. 13
    14. 14. Hashed Sharding © 2013 Aerospike. All rights reserved. Pg. 14
    15. 15. Hashing Sharding ➤ The key can be hashed using a hashing algorithm to create a seemingly random string ➤ The first several characters of the hash can be used to determine the node for that data. Paik C820G3KH15HH3KASD43S © 2013 Aerospike. All rights reserved. Pg. 15 Instead of using the actual key value, use a hash to randomize how the data is distributed.
    16. 16. Hashed Sharding Hashed sharding will balance data and load. © 2013 Aerospike. All rights reserved. Pg. 16
    17. 17. Hashed Sharding But has the same problem on a node failure. © 2013 Aerospike. All rights reserved. Pg. 17
    18. 18. Hashed Sharding Pros Cons + Easy to set up. Clients are written with a knowledge of how the data is distributed. + Servers aren’t coordinated, so no intra-cluster communication is necessary. + Data/traffic is now balanced. - If a node fails, the data on that node is unavailable. - Adding new nodes requires reconfiguration on the clients and re- shuffling of data on the server, resulting in service down time. - Replication must be handled separately. © 2013 Aerospike. All rights reserved. Pg. 18
    19. 19. Master-Slave © 2013 Aerospike. All rights reserved. Pg. 19
    20. 20. Master-Slave Master coordinates connection with slave nodes. © 2013 Aerospike. All rights reserved. Pg. 20
    21. 21. Master-Slave Sharding Pros Cons + Relatively simple setup with master controlling distribution. + Replication can be set up to go to backup node. Master is responsible for coordinating. - Adding new nodes requires reconfiguration on the master and often manual re-shuffling of data on the server, resulting in service down time. - Requires multiple network connections. - Single point of failure: the master. Some databases like Mongo require 3 masters (called configuration servers) where 2 will be backups for the main one. © 2013 Aerospike. All rights reserved. Pg. 21
    22. 22. Smart Partitioning The Aerospike Way © 2013 Aerospike. All rights reserved. Pg. 22
    23. 23. Smart Partitioning Every registrant knows where to go. © 2013 Aerospike. All rights reserved. Pg. 23 Map
    24. 24. Smart Partitioning And, every registrant knows where to go if a node fails. © 2013 Aerospike. All rights reserved. Pg. 24 Map
    25. 25. Smart Partition Architecture © 2013 Aerospike. All rights reserved. Pg. 25 Cluster creates a map of how data is distributed, called a partition map. Combine features from other architectures to create a map.
    26. 26. Smart Partitioning ➤ Every key is hashed using the RIPEMD160 hash function ➤ The creates a fixed 160 bits (20 bytes) string. ➤ 12 bits of this hash are used to identify the partition id ➤ There are 4096 partitions ➤ Are distributed among the nodes Paik 182023kh15hh3kahdjsh Partition ID Master node Replica node … 1 4 1820 2 3 1821 3 2 4096 4 1 © 2013 Aerospike. All rights reserved. Pg. 26 Aerospike uses a partition table
    27. 27. Smart Partitioning For simplicity, let’s take a 3 node cluster with only 9 partitions and a replication factor of 2. © 2013 Aerospike. All rights reserved. Pg. 27
    28. 28. Smart Partitioning Pros Cons + Relatively simple setup, with the cluster determining data distribution. + Balanced distribution. + No single point of failure. + Replication is automatic and immediate. + Failover is automatic and immediate. + Rebalancing is automatic and immediate. + An arbitrary number of nodes can be added to increase capacity. + True 24x7 uptime. Cluster can be upgraded on a rolling basis. - Application must be written using smart API. © 2013 Aerospike. All rights reserved. Pg. 28
    29. 29. What Do You Want From Horizontal Scaling? ➤ Hide the complexity of distribution.  Balanced data distribution. No “hot nodes.”  Automatic client reconfiguration. No need to manually reconfigure/restart clients. ➤ Linear scalability.  Easy to calculate needed capacity.  Cluster can be an arbitrary number of nodes. ➤ Better service availability.  24 x 7 uptime. No downtime, even for “routine” maintenance.  No single point of failure.  Automatic replication of data.  Automatic failover.  Automatic rebalancing when nodes fail.  Automatic rebalancing when adding nodes. ➤ Deal with a catastrophe on your data center. © 2013 Aerospike. All rights reserved. Pg. 29
    30. 30. So can you deal with a meteor hitting my data center? © 2013 Aerospike. All rights reserved. Pg. 30 But what about a meteor strike?
    31. 31. Multi-Datacenter Architecture © 2013 Aerospike. All rights reserved. Pg. 31 Data Center 1 Data Center 2 Data Center 3
    32. 32. Cross Data Center Replication (XDR) ➤ Asynchronous replication for long link delays and outages ➤ Namespaces configured to replicate to a destination cluster – master / slave, including star and ring ➤ Replication process  Transaction journal on partition master and replica  XDR process writes batches to destination  Transmission state shared with source replica  Retransmission in case of network fault  When data arrives back at originating cluster, transaction ID matching prevents subsequent application and forwarding ➤ In master / master replication, conflict resolution via multiple versions, or timestamp © 2013 Aerospike. All rights reserved. Confidential Pg. 32
    33. 33. Caveats for Evaluating Distributed Databases When testing new databases: ➤ Make sure to test to an appropriate scale. ➤ Beware of inconsistent performance in a cloud environment. ➤ If a database has caching, make sure your use is realistic. © 2013 Aerospike. All rights reserved. Pg. 33
    34. 34. THANK YOU © 2013 Aerospike. All rights reserved.

    ×