POC：POC测试，即Proof of Concept，是业界流行的针对客户具体应用的验证性测试，根据用户对采用系统提出的性能要求和扩展需求的指标，在选用服务器上进行真实数据的运行，对承载用户数据量和运行时间进行实际测算，并根据用户未来业务扩展的需求加大数据量以验证系统和平台的承载能力和性能变化。
Vertica：Vertica是一款基于列存储的MPP （massively parallel processing）架构的数据库。它可以支持存放多至PB（Petabyte）级别的结构化数据。Vertica是由关系数据库大师Michael Stonebraker(2014 年图灵奖获得者)所创建，于2011年被惠普收购并成为其核心大数据平台软件。
Altinity:Altinity是一家ClickHouse的服务供应商。
ClickHouse是一个非常好的分析数据库选择，不仅适用于初创公司，也适用于那些已经将大量资源投入分析解决方案，但对结果并不完全满意的公司。
在本文中，我们将讨论企业如何以及何时考虑ClickHouse迁移项目，以及他们可能会面临的挑战。我们没有透露公司名字，但每个例子都有一个真实世界的原型。
1.什么时候迁移？
迁移总是一个痛苦的过程。如果你搬到另外一个房子或者另一个数据库，这并不重要，但是总是要付出很多努力，这期间会经历困扰，挫折等等。但是最后的结果是值得挑战的，这是激励你继续前进的动力。那么考虑迁移到ClickHouse的动机是什么？
1.1 性能问题
其中一个主要原因是数据量大增，性能下降。使用流行的开源MySQL或PostreSQL数据库来实现一个demo甚至是生产系统是非常容易的。数据大小比较小，索引大小适合内存，数据缓存命中率足够高，在这样的情形下它能够正常提供服务。不幸的是，这样一个理想情形最终会走到尽头，查询会变得越来越慢。你可以通过增加更多的内存，订购更快的磁盘等等来解决问题，（这只是在纵向扩展），但这只是拖延解决本质问题：你该如何横向扩展你的数据库系统？
ClickHouse在这里可以帮到很多。即使在同一台物理服务器上运行，与OLTP数据库相比，它通常可以比OLTP负载快100-500倍的查询性能。如果还不够，ClickHouse集群可以很容易地堆出来，以解决任何规模的问题。
许多在性能问题上苦苦挣扎的公司，尝试了不同的开源替代方案，最终他们发现ClickHouse是他们的银弹。
1.2 横向扩展成本
在ClickHouse上市之前，很多公司已经使用商用DBMS部署了分析解决方案。惠普Vertica可能是最好的商用分析解决方案。Vertica价格是昂贵滴，但在不太大的TB级业务上，对于小公司来说价格也还负担的起。当业务要求将数据扩展10或100倍时，画面就不那么好看了（注意，数据量的成倍增加并不总是意味着公司利润的成倍增加）。商业数据库管理系统扩大数据收费会大大增加（虽然会提供一定量的折扣）。这种场景下有些公司可能会考虑更换数据平台。看这里，ClickHouse通过一系列专业知识来使硬件最大化发挥它们的功力。
1.3 持有成本
云数据库为分布式数据库部署提供了最快捷的解决方案。Google Big Query，Amazon RedShift或SnowflakeDB是非常好的产品。他们允许非常快速地安装并使系统能够正常运行。但是，一段时间以来，一些公司想知道快速启动的价格是否是长期合理的。我们已经在亚马逊和专用服务器上运行了一些ClickHouse的基准测试，并将其与RedShift进行了比较。例如，【通过这篇文章分析】，我们得出结论：在Amazon中运行ClickHouse的成本比类似执行的RedShift实例要低几倍。【这篇文章有介绍如何评估成本降低】，与Google Big Query和Athena相比ClickHouse明显胜出，并且会显著降低成本。
这里的另一个考虑是ClickHouse部署不是供应商锁定的。公司可以将ClickHouse解决方案部署到Amazon，专用服务器，私有云或KodiakData等专用云，从而以最灵活的方式优化其部署和成本结构。
2.如何迁移？
ClickHouse是一个不寻常的数据库，有很多很酷的功能和设计决策，以获得最佳性能。然而，学习如何最有效地使用ClickHouse需要一段时间。ClickHouse的限制显示了硬币的另一面。ClickHouse缺少一些比较成熟的数据库提供的功能。这使迁移项目变得复杂。
CH的一些限制：
不支持真正的删除/更新支持 不支持事务（与Spark和大部分大数据系统一样）
不支持二级索引（和Spark和大部分大数据系统一样）
自己的协议（不支持MySQL协议）
有限的SQL支持，join实现与众不同。如果需要在从MySQL或Spark进行迁移，则可能必须重新编写包含联接的所有查询。
不支持窗口功能
2.1 ClickHouse迁移的主要挑战
迁移到ClickHouse时，您可能会遇到以下挑战。
2.1.1 模式确认：
架构是性能的关键。因此，需要对ClickHouse最佳实践有很好的理解，表引擎如何工作，字典是什么等等。适当的模式能更好的发挥出ClickHouse的能力。
2.1.2 可靠的数据吞吐：
ClickHouse允许在一致性和速度之间进行平衡，这些权衡对于理解和管理很重要，特别是在分布式环境中。数据分配和复制、可扩展和可靠的系统需要恰当的设计。ClickHouse在数据分发和复制方面非常灵活，没有特定的方法。
2.1.3 客户端界面：
迄今为止，主要的ClickHouse问题之一是非标准的SQL语法。它是非常强大的，有很多扩展，但它不是标准的。这使得有时很难与使用SQL的客户端工具进行交互。这个问题已经被ClickHouse开发者很好的理解，我们可以期待ClickHouse在将来支持SQL-92或更高版本的标准。
2.2 做好准备
任何移植项目都应该从计划开始。我们提出以下方法来降低风险并确保迁移项目取得成功。
2.2.1 确认使用情况
确认ClickHouse是否适配业务是非常重要的。ClickHouse可能更适合流式或批次入库的时序数据。正如迈克尔·斯通布拉克（Michael Stonebraker）在10年前的游戏改变文章中所写的：“One size does not fit all” - ClickHouse不应该被用作通用数据库。
2.2.2 检查基准
有许多基准测试可用，您可以根据您已经使用的数据库找到基准。一些基准的链接可以【看看这里】。
2.2.3 运行自己的基准
眼见为实，使用真实数据运行基准并与现有生产系统进行比较总是很有意义。
2.2.4 仔细分析ClickHouse限制，而非功能
管理人员经常只注意功能，但忽略了局限性。开发人员往往更加怀疑这玩意是不是真的好用。ClickHose的特性确实好用，但更多的时候，它的限制可能会成为绊脚石。
你需要评估ClickHouse的各种限制，例如ClickHouse的分区限制，不支持更新和删除，不支持事务等等的缺点，是否和你的业务情形匹配。
但是并不要无端的害怕这些缺点，大多数情况下ClickHouse的限制可以被解决，甚至可以转化为好处。
2.2.5 做一个POC测试
部署并完整验证一个端到端的产品，并从中学习涉及到的ClickHouse知识、获得实践的专业知识等等。这些经验有助于真正的业务系统设计，也能够提前暴露系统实施时可能面临的大部分问题。
2.2.6 获取社区帮助
ClickHouse是一个开源数据库。所以最好的支持是社区。Yandex支持的telegram和google group是最好的地方，让新手学习更多，提出问题等等。即使你计划在某个时候获得Altinity的专业支持，自己也可以尽可能地学习。
3. 下一步工作
一旦上述所讲的先决条件步骤完成，你将获得适用于你方业务用例的一些ClickHouse专业知识，并且有信心评估ClickHouse是否适用于你的业务。如何进一步推进取决于你的系统的复杂性。之前的POC可能演变成生产部署，也可能你需要从头开始鼓捣点儿新玩意儿（因为某个业务的POC的场景不一定适用所有业务）。如果一个业务需要迁移，需要分析生产数据的时间要求，需要设计集成方案等等。正确的QA和测试也需要列入计划。
对于一些公司来说，只需几个星期就可以完全切换到ClickHouse，而庞大的项目可能需要一年的时间。
