我们部署的集群使用Cassandra，Elasticsearch和类似的NoSQL技术来索引和处理数据。 我们需要相当长的时间来确保我们能够快速消费和处理logging。
我们的一个客户要求我们导出他们的数据，以便在SQL Server中交叉引用它。 自从我在2008年的愤怒中使用SQL服务器已经有相当长的一段时间了，所以我现在可能与艺术有些脱节。
虽然客户端拥有数据中心和一系列熟练技术人员（DBA，开发人员等），但我们正在处理的部门却只有一台运行SQL Server 2014的服务器，而且技术知识有限。 这是一个拥有严格监pipe要求的庞大组织，通常需要花费数月的时间进行文书工作，处理和签署以获得资源分配。
他们要求我们将约730M条logging转储到他们的数据库中，然后build立一个过程来推送新数据。 从我们的结尾来看，这很简单，但是我担心他们是否能够真正使用这些数据。
logging长度可以变化，但是他们想要的信息大概在4k左右。
为了让事情变得更有趣，没有人似乎真的知道服务器有什么规格。 依靠他们使用的其他设备，我希望在64GB内存，RAID磁盘和6-12核心的东西。
我已经提到了几次，这可能是一个问题，只能得到模糊的保证，SQL Server可以处理这么多的数据。
现在…我知道SQL Server可以在分区，正确configuration时处理那么多的数据，并且拥有一个熟练的DBA来调整事物，但是如果没有人知道他们在做什么，过程？
由于获得新的设备/人员分配到他们的最终将是一个耗时的过程，他们的项目有一个紧迫的最后期限，我宁愿不要等到可怕的错误。
我知道没有人能用这么模糊的信息给我一个硬性规定，但是我应该关注什么？ 10M / 100M / 500M / 1B？
我不认为我能给你一个神奇的“在这里担心”这个数字，在这个数字之下的任何东西都是“好的”，而那个数字上的任何东西都是“坏的”。
这就是说，在你的问题上有一些红旗，至less在我看来：
好的，SQL Server可以绝对处理这些数据量。 我个人有四个服务器超过20TB。
但是，SQL Server与其他一些微软产品非常相似，因为如果你有一些只是轻微使用的小型数据库，你可以把它推到angular落，一般意义上说它就是正确的而不是咬你（至less不是马上），但是扩大需要更多的思考和努力。
我特别担心他们是否计划在服务器上进行适当的维护。 定期将“〜730Mlogging转储到他们的数据库中”，而无需事务日志备份将快速消耗他们的磁盘。
我也不被安慰：
他们试图从包括我们在内的三个独立系统中获得输出。 logging与其networking中的字段相关，因此具有在所有三个数据集中（在很大程度上）相同的URI。 他们需要三个表，每个提供者一个，然后join到一起回答问题。 他们计划在SSMS中完成所有这些工作，同时还有一些熟悉SQL Server /数据库的人员
我不确定这台服务器会不会很高兴，如果他们决定运行可怕的查询。 这听起来像数据可能不规范和/或可能不包含一个很好的连接键。
最后但并非最不重要的是，我有一些非常不愉快的经历：“我们决定通过让用户pipe理他/她自己的服务器来节省资金/让这个好孩子在邮件室里这样做/告诉他们我们赢了不支持，但他们可以做任何他们想做的事情。“ 它总是以昂贵和耗费时间来解决。