翻译原文：https://academy.datastax.com/planet-cassandra/mysql-to-cassandra-migration
原作者：Michael Kjellman is a San Francisco based Software Engineer. Michael works across multiple products, technologies, and languages. He primarily works on Barracuda’s spam infrastructure and web filter classification data. Follow him on Twitter at@mkjellman.
MySQL迁移到Cassandra
在超过15年的时间里，Oracle的MySQL已成为Web应用程序中事实上的基础架构，并得到广泛采用。这是有原因的：MySQL提供了一个可靠的关系数据库，使公司能够构建表现良好的系统。然而，即使是最强大的支持者也承认，它并不是为了应对新的大数据应用浪潮而设计的。需要管理大数据用例的现代企业正在转向Apache Cassandra来取代MySQL。
从MySQL迁移到Cassandra：通用建议
Cassandra适合您的应用吗？
新一类的NoSQL数据库已经被设计开发出来了，从传统关系数据库（如MySQL）中学习的18年以上的经验教训。Cassandra（和其他分布式或“NoSQL”数据库）旨在做出“正确”的权衡，
最终提供一个数据库，提供当今应用程序所需的可扩展性，冗余和性能。虽然MySQL过去可能已经表现良好，但新的业务需求， 你的应用程序要求提高的扩展行和可靠性可能意味着MySQL不再适合。
在进一步从MySQL转向Cassandra迁移之前，请先问自己：
“MySQL目前是开发新功能的障碍还是仍在为用户提供可接受的正常运行时间，可靠性和可扩展性？”
“否”：您不仅不应该迁移到Cassandra，而且您很可能不应该考虑迁移到任何替代数据库。将应用程序迁移到新数据库是一个非常困难，耗时且容易出错的过程。
“是”：希望您找到了一个有用的资源来指导帮助从MySQL迁移到Cassandra。有许多
可用的数据库，它们各有各的优点，缺点和权衡。本文并不是试图将Cassandra描绘成一个完美的解决方案; 事实上，我们会高亮强调Cassandra的权衡，优势和劣势。希望这将有助于您做出既知情又有教育意义的决定，而不是一个因为市场虚假宣传而改变的决定
不要试图在圆孔中推一个方形钉！
- Cassandra不是关系数据库。
- Cassandra不是MySQL的100％/“插入式”替代品。
- 只是将现有代码迁移到Cassandra而不做重新修改现有数据模型，将不会为您的应用程序带来完美的可用性或修复性能瓶颈。事实上，它可能会使事情变得更糟。
关键术语
以下是Cassandra术语概述，提供了描述及其与MySQL等价概念。目标是为了让我们能了解Cassandra而知道所需的最基本的术语和概念。要了解有关Cassandra的关键术语和体系结构的更多信息，您可以在 Cassandra architecture documentation中找到更多详细信息， 或请访问What is Cassandra得到更高层次的预览
如何处理数据？
在很高的层次上，Cassandra通过将所有数据均匀地分布在一组节点上来进行操作，这些节点可以被视为一个环。节点通常在商用硬件上运行。集群中的每个Cassandra节点负责并分配一个 令牌范围 （实际上是由分区器定义的一系列哈希值 ，默认为Cassandra v1.2+中的Murmur3Partitioner）。默认情况下，此哈希范围定义为最大数量的可能哈希值，范围从0到2 ^ 127-1。
每次更新或添加数据都包含唯一的rowKey （也称为主键）。对主键进行散列以确定node负责的令牌范围(tokenRange)是否包含该rowKey。然后将数据n副本存储在集群中（其中n由keyspace的复制因子定义），或者每个副本上一次负责给定查询的行键。Cassandra中的所有节点都是对等节点，客户端的读取或写入请求可以发送到集群中的任何节点，无论该节点是否实际包含并负责所请求的数据。没有master或slave的概念，节点通过gossip协议动态地了解彼此以及其他节点的状态和健康状况。接收客户端查询的节点称为协调器（cordinate）; 它负责了所有副本节点之间的查询通信（联系至少n个副本节点以满足查询的 一致性级别）并将结果返回给客户端。
读写
客户端可以通过原生二进制协议或Thrift协议与Cassandra进行读写。可以通过这两个传输方式进行CQL查询。但一般建议，如果您刚刚开始使用Cassandra，您应该坚持使用原生二进制协议和CQL并忽略Thrift。
当客户端执行读取或写入请求时，协调器节点会联系所需副本的数量，以满足每个请求所包含的一致性级别。例如，如果使用QUORUM一致性处理读取请求，并且创建的Keyspace的“复制因子”为3，则将联系所请求数据的3个副本中的2个，将其结果合并，并返回单个结果客户端。对于写请求，协调器节点将向所有副本节点发送包含所有修改列的写请求
本地处理写入
处理更新（也称为mutation）时，首先会在日志中添加一个条目 ，以确保事务的持久性，确保不丢数据。接下来，它也被添加到memtable中。memtable是一个有限的内存回写高速缓存，它包含尚未刷新 到SSTable的最近写入（一种持久的，不可改序列化的表数据磁盘文件）。
当更新导致memtable达到其配置的最大内存大小时，memtable将刷新为不可变的SSTable，将数据从memtable永久保存在磁盘上，同时为将来的更新腾出空间。在发生崩溃或节点故障的情况下，将从提交日志中重放日志，这可以防止在断电或异常崩溃时还没下刷memtables而丢失任何数据。
开发考虑
思考你的数据模型
从一开始就在Cassandra中创建一个深思熟虑的数据模型非常重要。糟糕的数据模型很容易破坏并消除您迁移到Cassandra的任何好处。对于MySQL，由于各种关系数据库功能（例如，使用复杂的JOINS），差的数据模型经常可以解决和适应。
虽然这些MySQL查询可能很慢而且成本很高，但如果有足够的时间和资源，就可以从数据集中获得准确的预期结果。使用Cassandra，追溯“修复”糟糕的数据模型要困难得多。首先，Cassandra中缺少JOINS会将复杂的读取移除掉。此外，由于Cassandra的强大功能和架构，可以比使用MySQL更容易地存储更多的行和数据。随着存储的数据量的增加，成功获得应用程序所需的给定性能边界内所需的确切数据会增加复杂性。只包含30行的SELECT查询将快速且可预测地返回。执行超过500万行的查询需要处理更多的IO。正如MySQL中的更多数据使复杂的JOINS更加困难，适应需要迭代多个节点和行的Cassandra数据模型将是缓慢，低效的，并且很可能根本不起作用。显然，在任何应用程序中，更快的数据库响应总是更好; 所以不要让你的数据模型成为应用程序中数据库延迟缓慢的原因！
非规范化
非规范化是数据模型设计中重要的概念，以便可以从一行和一次查询中得到查询结果，而不是从多个表和行进行多次读取以收集响应的所有必需数据，修改应用程序逻辑，将所需数据多次插入到将来可能需要它的每一行中。这样，所有必需的数据只需在一次读取中使用，这可以防止多次查找。
运维考虑因素
优化和调整Cassandra
在Cassandra中有很多选项可供调整。就像把你的汽车音响系统的高音，低音和音量调高到11对你的耳朵不好一样，当“优化”Cassandra以及它的许多按钮和表盘时，弊大于利。
key cache 和 row cache等选项是两个很好的例子。在MySQL世界中，大部分配置调优用于优化分配的各种缓存。在Cassandra世界中，这些设置实际上倾向于降低节点和集群的稳定性。Cassandra是用Java编写的，因此它必须在Java的限制范围内运行。最重要的考虑因素之一是垃圾收集 并且可以在不遇到大型垃圾收集相关问题的情况下实现堆的最大大小，这将影响Cassandra的性能。从带有CMS的JDK7（Cassandra 1.2.x和2.0.x中的默认值）开始，建议最大堆大小为8GB。必须在所有各种Cassandra组件之间共享此8GB。分配给key cache的2GB（显然）会在堆上再施加2GB的压力。缓存是一种优化而非要求，因此为缓存分配更多内存应该被视为整体情况的一部分。如果您可以将完整的8GB分配给Cassandra，建议首先将不超过768MB分配给key cache（key_cache_size_in_mb），将0MB分配给行缓存（row_cache_size_in_mb）。
另一个例子是multithreaded_compaction。虽然这似乎是一个明显的启用选项，但在大多数情况下，禁用此选项实际上可以提高整体群集的稳定性和性能。在许多情况下，少即是多。
迁移计划注意事项
维护数据完整性
有时迁移中最困难的部分不是编写一组可靠的脚本来从MySQL读取并插入到Cassandra中，而是一些简单的编码错误，这些错误可能导致MySQL和Cassandra版本数据之间出现严重的数据差异。
因为从MySQL迁移到Cassandra很可能需要更改数据模型，所以将关系型MySQL数据“转换”为非规范化形式所需的逻辑是迁移中最难的部分，当然也存在最大的风险。
不要将您的迁移脚本和逻辑视为一次性使用的，而是可以随时以任何顺序运行的生产级质量代码。迁移逻辑错误导致cassandra中的不一致版本迁移数据将会产生深刻影响
了解批量加载
无论您的迁移策略如何，在几乎所有情况下，您都必须将现有MySQL数据初始批量导入Cassandra。虽然简单地迭代每个MySQL结果并将结果一次一个地插入Cassandra可能很容易，但更有效的方法是使用 Cassandra Bulk Loader。在较高级别，批量加载程序要求您创建一个CSV文件，其中包含需要加载到Cassandra中的所有行和列。使用Java类 SSTableSimpleUnsortedWriter，您可以从CSV文件创建SSTable，然后可以使用SSTableloader将其直接加载到Cassandra中 。
有关更多详细信息和代码示例，请参阅http://www.datastax.com/dev/blog/bulk-loading上的文章
迁移方法
同步数据方法：
迁移到Cassandra并选择新的数据模型可能会显着增加数据库工作负载。或者，迁移后仍因一些过期旧脚本，您可能仍需要MySQL中的实时数据集。
从MySQL同步到Cassandra
在某些情况下，将Cassandra添加到遗留应用程序可能并不可行。在这种情况下，可能需要从MySQL到Cassandra的外部进程同步数据，同时并行运行新旧逻辑。
建议：
将时间戳列添加到要同步的MySQL表中。每次更新MySQL时，都会更新最新的时间戳。周期性间隔地从所有MySQL分片执行SELECT查询，其中最后更新的时间戳大于或等于上次同步开始的时间。
从Cassandra同步回MySQL
有些数据模型很难从Cassandra同步回MySQL（例如时间序列数据）。但是，
同步包含更多去标准化的“元数据”信息的行可以被同步回去。
什么是行不通的：创建一个每隔n分钟通过cron执行的同步脚本，并尝试从Cassandra执行SELECT * FROM TABLE（
然后更新并将所有这些记录插入MySQL）是一个失败的方法。Cassandra设计的固有特征是数据通过其key的散列值在多个节点上进行分片。执行SELECT * 查询是Cassandra反模式，应该避免。遍历所有节点上的每个键并返回单个分页数据集都是低效且不切实际的。
第一个建议：
当它修改Cassandra中的行时，应用程序另外写入队列。让脚本消费此队列，然后将更新批量插入MySQL。
第二个建议：
如果数据可以不那么实时更新到MySQL中，您可以编写一个Hadoop Map / Reduce作业，迭代您需要同步的列族。该解决方案提供了一种实用且可重现的方式来迭代列族中的所有键。使用此方法作为额外的健全性选项，以解决来自其他增量同步选项的错过的更新。
第三个建议：
另一个选择，如果你能够承受更大的延迟，从Cassandra更新回到MySQL之间的增量是使用SSTable2JSON等工具 将列系列SSTable转储为JSON格式，然后可以对其进行解析，然后用于更新MySQL。这是一种很笨拙的方法。此外，您必须编写逻辑以确保从所有节点转储SSTable以获取整个列族。
双写，然后剔除一个写目标方法：
如果您能够修改现有应用程序以与Cassandra连接，您最初可以通过双写数据库更新来启动迁移，一次写MySQL，另一次写Cassandra。一旦您将所有新更新写入MySQL和Cassandra，您就可以运行一个迁移脚本，该脚本遍历所有现有MySQL数据并将这些记录插入到Cassandra中。
最初，您可能希望将对Cassandra的写入实现为完全无阻塞，写入的操作。如果您在Cassandra部署期间遇到初始问题，请确保在Cassandra 宕机时不影响现有应用程序。
一旦您对即发即弃的写入感到满意，您就可以慢慢修改应用程序逻辑，开始从Cassandra而不是MySQL执行读取操作。感谢双重写入，如果遇到问题，只需恢复从MySQL执行读取操作即可。
用例和迁移资源
用例
AOL从mysql迁移了他们的文章索引，结果是写入量增加了8倍，并且认为迁移到Cassandra是“大赢”。
由于RDBMS的单点故障，Coursera遇到意外停机。此外，Cassandra使Coursera变得更有活力; 将超过900万用户介绍给一个随时可用的按需课程系统。
Mahalo
Mahalo的搜索技术被迫从MySQL迁移到Cassandra作为其主要数据存储，以实现更低的成本，更高的性能和可扩展性。
Pantheon Systems
Pantheon Systems为云中的Drupal网站提供平台，迁移到Cassandra主要是为了提高可扩展性和易用性。
Scoop.it的内容策划发布平台经历了MySQL在处理数据增长方面的局限性，并转向Apache Cassandra以实现可扩展性和不停服的要求。
Ampush
Ampush从MySQL迁移到Cassandra，因为它们增加了数据量，高可用性和性能要求，只有Cassandra才能满足。
Barracuda Networks
Barracudna Networks无法通过MySQL实时监控来自客户威胁，并向Cassandra寻求可扩展性和可用性优势。
Hailo
Hailo利用Cassandra建立了欧洲历史上最成功的创业公司之一。本演示文稿介绍了Hailo如何从简单的MySQL支持的基础架构发展成为在全球三个数据中心运行的弹性Cassandra支持的系统。
Ooyala
Ooyala选择Apache Cassandra具有弹性可扩展性和高性能 - 特别是当他们的MySQL环境不能满足客户服务水平时 - 帮助他们的客户在提供数字视频体验时采取更具战略性的方法。
AppsSavvy
AppsSavvy的目标广告投放解决方案从MySQL迁移到Cassandra，以提高负载下的可扩展性和性能。
Zoosk
Zoosk的持久通知系统已从MySQL转移到Apache Cassandra，因为它是一个高级数据库，用于大量的时间序列数据写入。
一旦他们的数据规模在MySQL上无法管理，Agentis Energy就不得不转移到Cassandra，因为他们现在存储超过150亿条时间序列能源使用数据的记录。
迁移资源
白皮书： 为什么要从MySQL迁移到Cassandra？ 作者：Robin Schumacher
本白皮书讨论了从MySQL迁移到Cassandra的“原因”和“如何”，以及良好的迁移候选者的外观。
Hindsight是20/20： MySQL到Cassandra。本次网络研讨会简要介绍了Barracuda Networks如何使用Cassandra以及他们如何替换他们的MySQL基础设施，Cassandra包括经验教训。此演示文稿中的幻灯片共享也是可用的： Hindsight是20/20：MySQL到Cassandra
Zoosk学习了5个经验教训，用于 moving persistent notifications from MySQL to Apache Cassandra，以便支持非常大量的写入，同时最大限度地减少写入延迟。
我们的钉钉二维码：
另外：阿里云cassandra服务也在公测中，欢迎大家使用。
https://www.aliyun.com/product/cds
