{
"tcp_flags": "0","src_as": "54321","nexthop": "1.2.3.4","unix_secs": "1352234521","src_mask": "23","tos": "0","prot": "6","input": "105","doctets": "186","engine_type": "0","exaddr": "2.3.4.5","engine_id": "2","srcaddr": "9.8.7.6","dst_as": "12345","unix_nsecs": "752265174","sysuptime": "2943529544","dst_mask": "24","dstport": "80","last": "2943523241","srcport": "52672","dpkts": "4","output": "111","dstaddr": "6.5.4.3","first": "2943517993"
}
我们希望能够对数据集进行快速搜索(少于10秒),最有可能在很短的时间内(10 – 30分钟间隔).我们还希望索引大部分数据点,以便我们可以快速搜索每个数据点.我们还希望在执行搜索时获得最新的数据视图.留在开源世界会很棒,但我们并不反对为这个项目寻找专有解决方案.
这个想法是保留大约一个月的数据,这将是约432亿条记录.粗略估计每条记录将包含大约480字节的数据,相当于一个月内大约18.7太字节的数据,可能是索引的三倍.最终,我们希望增加此系统的容量来存储数万亿条记录.
我们(非常基本上)已经对这个项目的候选人进行了评估,但是每个人都提出了自己的挑战.使用couchbase时,索引是按时间间隔完成的,而不是在插入数据期间,因此视图不是最新的,cassandra的二级索引在返回结果时效率不高,因为它们通常需要扫描整个集群以获得结果,而mongodb看起来很有希望但是由于它是主/从/分片,因此看起来更难以扩展.我们计划评估的其他一些候选者是elasticsearch,MysqL(不确定这是否适用),以及一些面向列的关系数据库.任何建议或现实世界的经验将不胜感激.
解决方法
理论
>分类您的数据.单个服务器无法可靠且真实地保存这样的数据量.
>为硬件故障和整个节点故障做好准备,复制数据.
>从一开始就开始使用许多后端服务器.
>与顶级高性能服务器相比,使用更便宜的商用服务器.
>确保数据在分片中均匀分布.
>花大量时间来规划您的查询.从查询中派生API,然后仔细设计表.这是最重要和最长期的任务.
>在Cassandra中,您可以设计复合列密钥并在O(1)中访问该密钥.花时间研究它们.这将用于访问可搜索记录而不是二级索引.
>利用宽行.它们对于存储带时间戳的事件非常有用.
>切勿在此类音量上执行全扫描或实际上超过O(Log N)的任何操作.如果您需要超过O(Log N)的任何内容,请将此类操作卸载到Map-Reduce算法.
实践
>不要花时间在物理机器上构建操作系统映像或安装服务器.使用基于云的提供程序进行快速原型设计.我曾与Amazon EC2合作,因其简单性,可靠性和原型制作速度而备受推崇.
> Windows机器在启动时往往较慢,并且需要更多资源处于空闲状态.考虑使用基于Unix的操作系统.就个人而言,我发现ubuntu服务器是一个可靠的操作系统,而且在askubuntu有一个非常好的社区
>考虑网络,理想情况下节点应该彼此接近以允许快速闲聊和元数据交换.
>不要进入极端情况：非常宽的列行或特别长的列族(表).在理智的边界中实现最佳性能 – 如果db通过设计支持那么多N行,并不意味着它表现良好.
>我们的搜索大约需要3-5秒,这主要归功于UI和数据库之间的中间节点.考虑如何将请求更接近数据库.
>使用网络负载平衡器.选择一个已建立的.我们使用HAProxy,它很简单,但速度很快.从来没有遇到过问题.
>简化复杂的解决方案.
>寻找免费的开源解决方案,除非您得到公司规模预算的支持.一旦你去了多台服务器,基础设施的成本可能会高得惊人.
我不为亚马逊工作,与HAProxy和Ubuntu团队没有任何关系.这是一种个人观点,而不是任何形式的宣传.
