Olery 差不多成立于5年前。始于Ruby代理开发的单一产品(Olery Reputation)，随着时间的推移，我们开始致力于一系列不同的产品和应用程序。当今，我们的产品不仅有(Olery) Reputation，还有Olery Feedback, Hotel Review Data API,widgets ，在不久的将来它可以嵌入到网站和更多产品/服务中。
我们增加了很多应用程序的数量。当今，我们部署了超过25个不同的应用程序(全为Ruby)，它们中的一些是web应用程序(Rails或者Sinatra)，但大多数的是后台运行程序。
我们最引以为豪的是迄今为止我们所取得的成就，不过在这些成就的背后总闪现着一样东西,即基础数据库。从Olery成立之日起，我们就安装了数据库，它用MySQL来存储（用户、合同等等）核心数据，用MongoDB来存储评论及其类似的数据（即哪些在数据丢失的情况下很容易恢复的数据）。一开始，这样的安装运行的非常好，然而，随着公司的成长，我们开始遇到了各种各样的问题，尤其是MongoDB的问题居多。其中一些问题是由于应用与数据库的交互方式而引起的，一些则是由数据库本身而产生的。
例如，某个时刻，我们需要从MongoDB中删除一百万个文档，以后再把这些数据重新插入到MongoDB里。这样的处理方法使得整个数据库几乎要被锁定数个小时，自然服务性能就会降低。而且直到对数据库执行修复（即在MongoDB上执行repairDatabase命令）后才会解锁。而且完成修复还要花费数个小时，修复所花的小时数要根据数据库的大小来确定。
在另一实例中我们注意到我们的应用程序的性能降低和设法跟踪到的 MongoDB 集群。然而，经过进一步检查，我们无法找到问题的真正原因。无论我们怎么安装，或使用什么工具敲了什么命令我们都找不到原因。直到我们更换了集群的初选，性能才恢复正常。
这只是两个例子，我们已经有过许多这样的情况。这个问题的核心是，这不只数据库在运行，而且无论我们何时察看它都没有绝对的迹象表明是什么原因导致的问题。
无模式的问题
另外，我们面对的核心问题是mongoDB的重要特征之一：模式的缺乏。模式的缺乏可能听起来是有趣的，并且在一些情况下是有好处的。然而，对于许多无模式存储引擎的用法，其导致了一些模式之间的内部问题。这些模式没有通过你的存储引擎定义而是通过你的应用的行为及其可能的需要而定义的。
例如：你可能有一页存储你的应用需要的字符串类型的title字段的集合。这儿这个模式是非常符合当前情形的，即使它没有被明确的定义。但如果这个数据结果改变超时，尤其是如果原来的数据没有被迁移到新的数据结构，这就成了问题（在一些无模式的存储引擎上是相当有问题的）。例如，你可能有下面这样的Ruby代码：
post_slug = post.title.downcase.gsub(/\W+/, '-')
这样，针对每一个有“title”字段并返回一个String的文档，它都能正常工作。然而，对于那些使用不同字段名字（例如：post_title）或者根本没有标题字段的文档来说，它将不能正常工作。为了处理这种情况，你需要将代码调整为下面内容：
if post.title
post_slug = post.title.downcase.gsub(/\W+/, '-')
else
# ...
end
另一种处理方法是，在你的模型中定义一个模式。例如 Mongoid，一个流行的针对Ruby的MongoDB ODM，就能让你做到这一点。然而，当使用这些工具定义一个模式时，你可能会好奇为什么它们不在数据库内定义该模式。实际上，这样做可以解决另一个问题：可重用性。如果你只有一个应用程序，那么在代码中定义模式并不是什么大问题。然而，如果你有许多应用程序的话，这将很快会成为一个大麻烦。
无模式存储引擎希望通过删除对模式的限制的方式，让你的工作变得更简单。但现实的情况是，确保数据一致性的责任推到了用户自己的身上。有时候无模式引擎可以工作，但我打赌，更多的时候是事与愿违。
好数据库的需求Olery有了更多的特殊需求后，迫使我寻求一款更好的数据库来解决问题。对于系统，特别是数据库，我们非常注重以下几点:
一致性
数据和系统行为的可视化
正确性和明确性
可拓展