Fly*_*ana 7 sql database amazon-dynamodb
脚本
假设我正在为Messenger应用程序构建数据库.让两个表,一个User表和一个Conversation表.每个对话都有一个参与用户列表,每个用户都有一个他们所在的对话列表.简而言之,用户和对话表之间存在多对多关系.
现在假设我想在打开应用程序时按降序按时间顺序加载用户对话列表的前10个对话.假设表中的#Conversations >> #Conversations用户有>> 10,一种强制方式是加载用户列表中的每个会话,然后在内存中排序,最后返回第10个.我想这是怎么回事普通的SQL引擎将处理这样的查询.
关心
我担心的是,当#Conversations用户变得非常大时,此操作变得太耗费资源.是否有更快的方法来实现相同的结果(从表中获取已排序的记录子列表)以及可能的其他数据库设置？
例
例如,假设用户有300个会话,我们希望按顺序翻阅这些会话.上述方法可以将所有300个会话下载到磁盘,然后在本地进行排序,或者让服务器进行排序.第一种方法使用太多带宽,信息可能不是最新的,第二种方法需要在每次页面浏览时从数据库中提取所有300个对话.
题
我的问题是:我对这个特殊情况的关注是否有效？如果是这样,我应该如何修改我的数据库设置以避免此问题？一些现有的例子如Facebook Messenger如何处理这个？如果没有,为什么这不是性能问题？
编辑
我在问了一个问题之后才意识到在RDBMS中我们只需要创建第三个表来存储多对多关系,并在这个表上构建索引就可以解决这个问题.但是,在这种情况下,支持列中存储列表的NoSQL数据库(更具体地说,AWS DynamoDB)是否优于传统的RDBMS？
是否有任何更快的方法可以通过可能的额外数据库设置来实现相同的结果（从表中获取已排序的记录子列表）？
就在这里。
这种“附加数据库设置”称为“索引”。我认为每个关系型 DBMS 都允许创建索引。
索引可以有多种类型，但最常见的是 B 树索引，其中数据存储在平衡树中，这样可以快速找到必要的元素并按照索引的顺序读取数据。已排序。
索引是数据库引擎除了主表数据之外在磁盘上存储和维护的补充结构。您通常可以在同一个表上创建许多不同的索引。引擎在运行特定查询时会尝试选择最合适的索引。不同的查询可能使用不同的索引。
由于当基础数据发生变化时必须维护索引结构，这意味着通常创建索引有助于查询SELECT，但会降低速度UPDATE，DELETE并且INSERT。这就是为什么它通常是一种权衡，并且需要一些技巧来确定应该存在哪一组索引。这很大程度上取决于运行的查询类型及其相对重要性。
有关如何借助适当索引实现高效分页的具体示例，请查看网站上的Pagination Done the Right Way ，即使用索引，Luke。
它还对SQL 索引剖析以及许多其他有用的文章进行了很好的介绍。
我对这个特殊案例的担忧是否有效？
它对于 300 行无效，但随着表大小的增长而变得越来越重要。对于 3 亿行来说，这很可能相当重要。