cla*_*son 7 database-design web-services scalability
我正在寻找一些关于工作中可能需要解决的问题的架构思路.
问题.
1)我们的企业LDAP已经成为一个"联系主人",充满了多年陈旧数据以及未使用和未维护的属性.
2)管理层已决定LDAP将不再作为公司电话簿.它仅用于授权目的.
3)公司有关于数百种不同来源的人的联系方式数据.我们需要清除LDAP中的所有垃圾,并为其他应用程序提供一个中央存储库来存储有关一个人的所有这些数据.
理想的目标
1)有一个单一的来源存储关于一个人的所有各种属性
2)公司可能有500k人的信息(读500K行)
3)我估计这些人可能有500到1000个可选属性.(阅读500多列)
4)数据主要通过jml在jms上设置/获取(此基础结构已经到位)
5)公司内的各个组可以"拥有"列.只有他们被允许写入他们的列,他们将负责保持数据清洁.
6)应在子秒内返回单个记录查找
7)系统应在峰值时支持每小时100万个请求.
8)主要目标是向企业提供实时数据,报告是次要目标.
9)我们是一个java,oracle,terradata商店.我们是您典型的大型IT商店.
我的想法:
1)最初我认为LDAP可能有效,但是在添加新列时它不会扩展.
2)我的下一个想法是某种无sql解决方案,但从我所读到的,我不认为我不能得到我需要的性能,它仍然相对较新.我不确定我是否可以让我的经理为这样一个关键项目签署类似的东西.
3)我认为解决方案中将有一个元数据组件,它将跟踪谁拥有列以及每列代表什么,以及原始源系统.
感谢阅读,并提前感谢任何想法.
借助 Teradata 级工具，基于 SQL 的解决方案可能是可行的。不久前我看到一篇关于数据库设计的文章，讨论了“锚定建模”。
基本上，这个想法是创建一个单一的、愚蠢的、合成的主键表，而所有真实或元数据都存在于其他表（子集）中，并通过外键+连接的方式附加。
我认为这种设计有两个好处。首先，您可以出于组织或性能原因更轻松地划分数据存储。其次，您只需为在任何给定子集中具有数据的记录创建额外的行，因此您使用的空间更少，索引和搜索速度更快。
子集可能基于维护者或其他一些标准。XML set/get 将针对每个子集/记录（而不是全局记录）。给定记录的所有子集都可以组合并缓存。可以为元数据、搜索索引等创建附加子集，并且可以独立查询这些。
NoSQL 看起来与 LDAP 类似（至少在理论上），但是一个好的 NoSQL 工具的好处包括对元数据、版本控制和组织的更大抽象。事实上，从我所读到的内容看来，NoSQL 数据存储旨在解决您提出的有关扩展和松散结构数据的一些问题。SO有一个关于数据存储的好问题。
目前，有少数大公司在大规模环境中使用 NoSQL，例如Google 的 Bigtable。它似乎是以下方面的完美工具：
6) 单个记录查找应在亚秒内返回
7) 系统应在高峰时支持每小时 100 万个请求。
据我所知，Bigtable 只能通过AppEngine获得。此处列出了其他类似的技术。
无论您决定使用哪种技术，更大的图片视图看起来或多或少都是相同的。例如，划分存储、复合视图、缓存视图、将元数据粘贴到某处以便您可以找到东西。
您所瞄准的性能特征将需要基于实际使用模式的某种缓存和/或优化。无论您选择哪种解决方案，您都可能无法在设计阶段解决该问题。