我正在寻找一些关于工作中可能需要解决的问题的架构思路。
问题。
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）我认为解决方案中将有一个元数据组件，它将跟踪谁拥有列以及每列代表什么，以及原始源系统。
感谢阅读，并提前感谢任何想法。
答案 0 :(得分：3)
使用Teradata级工具，基于SQL的解决方案可能是可行的。前一段时间我遇到了一个article on database设计，讨论了"anchor modeling"。
基本上，我们的想法是创建一个单一的，愚蠢的，合成的主键表，而所有真实或元数据都存在于其他表（子集）中，并通过外键+附加加入。
我认为这种设计的好处是双重的。首先，出于组织或性能原因，您可以更轻松地划分数据存储。其次，您只为任何给定子集中拥有数据的记录创建其他行，因此您使用的空间更少，索引和搜索速度更快。
子集可能基于维护者或其他一些标准。 XML set / get将是每个子集/记录（而不是全局记录）。可以合成和缓存给定记录的所有子集。可以为元数据，搜索索引等创建其他子集，并且可以单独查询这些子集。
另一方面，有少数几家大公司在大规模环境中使用NoSQL，例如Google's Bigtable。它似乎是完美的工具：
6）应在子秒内返回单个记录查找 7）系统应该在峰值时每小时支持100万个请求。
Bigtable只能通过AppEngine提供（据我所知）。其他类似的技术是listed here。
无论您决定使用何种技术，更大的图片视图看起来大致相同。例如。划分存储，复合视图，缓存视图，在某处粘贴元数据，以便您可以找到它们。
您要定位的性能特征需要基于实际使用模式进行某种缓存和/或优化。无论您选择何种解决方案，您都可能无法在设计阶段解决这个问题。
答案 1 :(得分：2)
一些想法：
1）我们的企业LDAP已经成为一个“联系主人”，充满了多年陈旧数据以及未使用和未维护的属性。
这不是一个真正的技术问题。您也可以使用新系统，LDAP或不具备此问题。
“LDAP ...无法扩展”
有很多巨大的 LDAP系统。 LDAP肯定是一个黑暗的艺术，但我愿意打赌它在这种情况下比任何SQL等价物更好地扩展。更不用说LDAP是这种信息的标准，因此可以从数以万计的不同类型的系统中访问它。
也许您正在寻找的是一个更易于管理/拥有更好管理工具的新LDAP系统？
答案 2 :(得分：1)
你可能想看看Len Silverston的派对模特。这是他的书的链接：http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237。
我没有在这种规模上构建某些东西的经验，尽管我认为将其视为500k行x 500-1000列听起来有点荒谬。