选择一款任务关键型应用软件时，绝不能犯错。
贵公司下令采用更多的开源数据库技术，为此招你来选定正确的方向。无论你是开源技术老手还是新手，这都是一项艰巨的任务。
过去这几年，开源技术在企业界的采用稳步增长。人气急升的同时带来了拥挤的市场，众多开源软件公司承诺自己的解决方案可解决所有问题，适应所有工作负载。对这样的承诺可要小心。选择合适的开源技术(尤其是数据库)是一个重要且困难的决定，不可掉以轻心。
我在Percona及其他公司担任过IT专业人员，有幸亲自采用过开源技术，并指导其他人做出正确的决策。有许多重要因素要考虑，但愿本文能阐明几个因素。
1. 要有目标。
这听起来很简单，但从我与接触MySQL、MongoDB或PostgreSQL的许多同行的对话来看，这一点最重要。
为避免被市场上无穷组合的开源数据库软件所淹没，牢记一个具体的目标。也许你的目标是为内部开发人员提供由内部数据库团队管理的一个标准化的开源数据库后端，也许你的目标是使用新的开源技术，丢弃并更换遗留应用软件和数据库后端的全部功能。
一旦你确定好了目标，可以集中精力。这样与企业内外的开源数据库软件供应商和支持者交流起来更顺畅了。
2. 了解你的工作负载。
尽管数据库技术越来越有能力身兼数职，但每项专注于某些领域，比如MongoDB现在是事务数据库，MySQL现在拥有JSON存储。开源数据库一个日益盛行的趋势是，提供声称某些功能可用的复选框。最大的错误之一是，没有使用合适的工具处理相应的任务。某个因素会导致公司误入歧途――也许是过度狂热的开发人员或眼光狭窄的经理。遗憾的是，错误的工具可能适用于少量的事务和数据，但之后会出现瓶颈，只有使用不同的工具才能消除。
如果你想要数据分析仓库，开源关系数据库可能不是合适的选择。如果你想要事务处理应用软件，并有严谨的数据完整性和一致性，NoSQL数据库可能不是合适的选择。
3. 避免重新发明轮子。
在过去这几十年，开源数据库技术迅猛发展，取得了长足的进展。我们已看到了转变，由新颖的、适合生产环境问题的新数据库，转向成熟的企业级数据库后端。不再非得是站在前沿的早期采用者才可以选择开源数据库技术。众多企业已围绕这些社区发展起来，在开源数据库领域为越来越多的初创公司、中型企业和《财富500》强公司提供生产级支持和工具。
Battery Ventures是一家专注于技术的投资公司，最近推出了BOSS指数，用于跟踪最受欢迎的开源项目。这份指数并不完美，但有助于我们了解一些最广泛采用、最活跃的开源项目。数据库技术占了榜单的大多数席位(十大技术中的五项)，这不足为奇。刚接触开源数据库领域的人应该看看这份指数榜单。很多时候，供应商已经开发出了解决特定问题的合适架构。
我的观点是，有人可能已经做了你想要做的事情。借鉴成功，汲取教训。即使某个解决方案不是非常合适，可能也可以稍加改动，适合你的要求。比如说，亚马逊提供了CloudFormation脚本，用于在其EC2环境中部署MongoDB。
如果你是站在前沿的早期采用者，并不意味着无法探究。如果你有独特的挑战或工作负载似乎适合一项新的开源数据库技术，就用吧。请记住，早期采用者面临固有的风险(和回报!)。
4. 开始很简单。
你的数据库果真需要几个9?对许多公司而言，“实现高可用性”常常是个模糊的目标。当然，最常见的答案是“它是关键任务型，我们无法承受任何停机时间。”
数据库环境越复杂，管理起来越困难、越费钱。理论上你可以获得更长的正常运行时间，但那样将牺牲可管理性和性能。如有疑问，一开始要简单。需要时总是有办法进行扩展。
比如说，Booking.com是广为人知的旅游预订网站。可能不太广为人知的是，它使用MySQL作为数据库后端。Booking.com的高级系统架构师Nicolai Plum曾概述过该公司的MySQL数据库的发展历程。其中一个心得是，数据库一开始很简单。数据库势必会随着时间的推移而发展，但一开始，简单的主副本架构足够了。随着工作负载和数据集不断增加，它引入了负载均衡器、多个读取副本、归档到Hadoop以分析数据等。但是早期的架构极其简单。
5. 如有疑问，咨询专家。
如果你不确定数据库是否合适，在论坛和网站上多转转，或者联系供应商。你可以研究哪些数据库技术满足要求，哪些数据库技术满足不了。常常有一些合适的替代方案是你之前没考虑过的。开源社区的宗旨就是分享知识。
在联系开源软件和服务供应商联系时，要注意很重要的一点。许多供应商奉行开放/核心商业模式，鼓励采用数据库软件。不要盲目地听取对方的建议或指导，自己调研一番，并探究替代方案。
结束语
选择合适的开源数据库是个重要的决定。先要提出合适的问题。人们往往本末倒置，还没有真正了解需求就做出决定。
原文标题：5 tips for choosing the right open source database，作者：Barrett Chambers
