1 sql-server database-design multi-tenant
总而言之,我是一名贸易程序员,但对于这个特殊的项目,我自己也是DBA.这是我面临的情景:
适用于400-1000客户的Web应用程序.客户是"实体公司",每个公司都有n个.每个客户(公司)平均拥有1GB的数据(总共约2亿行).每个公司在存储的数据类型方面可能有80%的相似数据.另外20%是公司自己定义的自定义数据(基本上是自定义字段).
当你发现客户需要相当不错的反应时间时,我试图找出以便宜的方式扩展这种方法的最佳方法.例如,客户X可能想要获取姓氏为"史密斯"的所有记录,以及像"555"这样的电话,其中客户Y可能想要获取帐号等于"1526A"的所有记录.
最重要的是,性能是关键,我发现很难决定索引什么,如果这甚至会帮助我,因为这些人基本上可以通过UI创建自己的查询.
我的问题是,你会做什么？您是否认为将每个客户分解为自己的数据库是明智的？目前的DB总大小约为400GB.
这是一个完整的重写,所以我有幸能够在需要时重新开始.任何想法,提示将不胜感激.
最重要的是,性能是关键,我发现很难决定索引什么,如果这甚至会帮助我,因为这些人基本上可以通过UI创建自己的查询.
最重要的是,您将数据库性能视为客户的一时兴起.如果他们能够"创建自己的查询",那么他们就能够"创建自己真正糟糕的查询".
因此,如果您在共享环境(即相同的硬件)中运行此操作,那么客户A的糟糕表扫描可能会使其他人的I/O饱和.
如果它们位于同一数据库服务器上,则客户A的扫描会从数据高速缓存中清除所有其他客户数据.
基本上,您"分享"越多,客户就越能影响其他客户的运营.如果你让客户有能力做昂贵的事情并分享大部分内容,那么每个人都会受苦.
因此,选项是:a)不要让客户做愚蠢的事情或b)保持客户尽可能分开,这样当一个人做傻事时,电话不会点亮所有其他客户.
如果你不知道"索引什么",那么你就无法控制客户可以做什么,因此愚蠢的事情因素也会上升.
您可能会通过提供客户可以选择的几种流行的预制SQL视图而获得相当远的结果,然后它们仅限于过滤并可能对结果进行排序.然后围绕这些视图的执行进行优化.
令人惊讶的是,很少有"一般"视图可以涵盖大量的用例.
通用,愚蠢的查询可以委派给在夜间,非工作时间运行的批处理,或者委托给不影响事务性能的单独计算机,例如带有"除了今天数据之外的所有数据"的夜间快照.让他们对此进行历史性查询.
| 归档时间： |
|
| 查看次数： |
525 次 |
| 最近记录： |