分表存储查询

㈠ 分布式数据库片段查询是什么

一些多机查询计算场景下，要求合并多机数据源，假设某个需求需要将数据再次计算。

计算的列不在select查询中，拿回来的多机数据源因为没有需要计算的列，就无法计算。

通过记录原来select的列数，将需要再次计算的列附加到select列中，待计算完毕后，按照原来的select列数将数据发送给客户端。

本方案应用于多机查询处理中（分布式数据库），结合数据定义配置，使用本方法能够获取到查询需要的额外列是否真实有效，结合数据散列方法优化本方法的使用。

Original query：原始查询，一般是用户发给数据库的查询语句；Sytax tree：语法树，用户发送给数据库的查询语句，通过解析器生成的一个可供代码处理的逻辑结构；Fetch select list:这个动作是获取SELECT查询语句中的查询列。

Have group:这个动作是检查SELECT查询语句中是否存在GROUP关键字。Have order:这个动作是检查SELECT查询语句中是否存在ORDER关键字。Select list:一个存储SELECT语句中查询列的数据结构。

Select list, [group list, order list]：修改后的查询语句格式，括号里面的新增列，是附加到原始列后面的。

原始sql解析成语法树结构，该语法树能够提供一个代码结构，后续处理流程会使用到这个代码结构。首先扫描SELECT查询的列，将SELECT的列存储到SELECT LIST结构中。

扫描语法树查看是否有GROUP（分组）关键字存在，如果存在，需要判断GROUP分组的列在SELECT LIST中是否已经存在，如果不存在，则将GROUP分组列增加到SELECT LIST中，并将GROUP分组列附加到原查询语句的查询列尾部，并且记录下分组列在查询列中的位置。

扫描语法树查看是否有ORDER（排序）关键字存在，如果存在，需要判断SELECT LIST是否已经存在ORDER排序列，如果ORDER排序列没有包含在SELECT LIST中，则将ORDER排序列放入SELECT LIST中，并且将ORDER排序列附加到查询语句尾部，标记ORDER排序列在查询语句中的位置。

经过处理流程1，2，3，4就将客户端发送给数据库的原始查询语句改写为新的查询语句，下面使用一个具体例子来说明实际处理过程。

例：Original query（原始查询语句，客户端发送给数据库的查询语句）：SELECT email FROM userInfo WHERE create_time > ‘2011-11-11’ GROUP BY name order by id desc。

syntax tree：SQL解析后的语法树（略，这是其他独立模块提供的），Fetch select list：扫描语法树，可以发现SELECT查询的列有email，因此，将email存放到SELECT LIST。

Have group:扫描语法树，发现有GROUP关键字，分组列name不存在与SELECT LIST中，因将name放入SELECT LIST中，并且将name附加到查询列后面。

这时候SQL语句为SELECT email, name FROM…，标记分组列name在查询中的位置为1（从左到右，从0开始，email位置为0，name为1）。

Have order扫描语法树，发现有ORDER关键字，排序列为id，该列不在SELECT LIST中，因此将排序列ID附加到查询语句中，查询语句变为SELECT email, name, id FROM … ，标记排序列在查询中的位置为2。

经过一系列处理流程，那么为了实现这次查询，已经将查询重写改写为形成一个新的查询：SELECT email,name, id FROM userInfo WHERE create_time > ‘2011-11-11’ GROUP BY name ORDER BY id DESC。

所得到的信息有：原始查询的列数，改写后的列数，分组列位置，排序列的位置。使用处理后的SQL语句从数据存放点取回数据，根据所得到的信息，依次执行分组，排序，然后再发送的时候，按照原始查询的列数发送数据到客户端。

分库分表后能够支持复杂查询，如GROUP、ORDER等等；数据存储节点参与计算，相比直接把数据全部查询到应用程序中进行计算，具有更小的网络开销，更快的计算速度。

在多机查询中，不需要应用程序参与查询计算；通过关系代数等价变化的方式，重写查询语句，让数据节点参与查询计算的方式，相比常规方案性价比要高。

㈡ 大数据量最近的存储分表常见算法

大数据量最近的存储分表常见算法
当一个应用的数据量大的时候，我们用单表和单库来存储会严重影响操作速度，如mysql的myisam存储，我们经过测试，200w以下的时候，mysql的访问速度都很快，但是如果超过200w以上的数据，他的访问速度会急剧下降，影响到我们webapp的访问速度，而且数据量太大的话，如果用单表存储，就会使得系统相当的不稳定，mysql服务很容易挂掉。所以当数据量超过200w的时候，建议系统工程师还是考虑分表.
以下是几种常见的分表算法。
1.按自然时间来分表/分库;
如一个应用的数据在一年后数据量会达到200w左右，那么我们就可以考虑用一年的数据来做为一个表或者库来存储，例如，表名为app，那么2010年的数据就是app_2010，app_2011;如果数据量在一个月就达到了200w左右，那么我们就可以用月份来分，app_2010_01，app_2010_02.
2.按数字类型hash分表/分库;
如果我们要存储用户的信息，我们应用的注册量很大，我们用单表是不能满足存储需求的，那么我们就可以用用户的编号来进行hash，常见的是用取余操作，如果我们要分30张表来存储用户的信息，那么用户编号为1的用户1%30=1，那么我们就存在user_01表里，如用户的编号为500，那么500%30=20，那么我们就将此用户的信息存储在user_20的表里.
3.按md5值来分表/分库;
我们假设要存储用户上传的文件，如果上传量大的话，也会带来系统的瓶颈问题，我们做过试验，在一个文件夹下如果超过200个文件的话，文件的浏览效率会降低，当然，这个不属于我们本文讨论的范围，这块也要做散列操作.我们可以用文件的用户名来md5或者用文件的md5校验值来做，我们就可以用md5的前5位来做hash，这样最多我们就可以得到5^5=3125个表，每次在存储文件的时候，就可以用文件名的md5值的前5位来确定这个文件该存那张表.
4.实例:某微博的url加密算法和存储策略的猜想.
现在好多微博都用这样的url来访问，如果他们的域名为www.example.com，那么如果你发微博的时候，你会发现你所发的url都变成了http://t.cn/Mx4ja1，这样的形式，他们是怎么进行这样的转换呢?我猜想就是用到了我们上面讲的md5的存储和查找规则，用你发的url来进行md5，得到md5值之后，如我们例子来说，就会用前6位来进行分表.
5.分表所带来的问题.
分表也会带来一系列的问题，如分页的实现，统计的实现，如果我们要做一个所有数据的分页，那么我们得每张表都得遍历一遍，这样访问效率会很低下.之前我尝试过用mysql的代理来实现，最终用tcsql来实现了.
6.分表算法的选择.
首先，分表适合于没有大的列表的应用来使用，要不然，会为这部分做好多额外的工作，如果你的应用数据量不是特别大的话，最好别用分表。7.针对每秒插入数据500+的设想为什么要这个呢，因为很多数据库在数据上千万级别后，每秒插入数据的数度不是很快了，所以500/秒的速度够呛，解决方案设想：建立数据总表及两个缓冲表，结构完全相同，将数据先插入其中一个缓冲表中，等到一定时间(插入效率降低之前)，转向插入另一个缓冲表，同时启动一个后台进程将第
一个缓冲表的的数据转入总表，转入总表后删除第一个缓冲表中的数据; 再等到一定时间(还是插入效率降低之前)，转向插入第一个缓冲表，这时启动一个后台进程将第
二个缓冲表的的数据转入总表，转入总表后删除第二个缓冲表中的数据; 如此循环往复...

如果后台进程处理的时间超过两个缓冲表的循环周期的话，甚至可以考虑建立三个乃至四个缓冲表。

这仅仅是解决插入效率，查询什么的问题也大。

㈢ 数据库分区、分库和分表的实现方式！

数据库分区、分库和分表是提升大型数据库系统性能与可靠性的关键策略。它们针对的是数据存储量不断增长的挑战，旨在优化数据库操作，包括查询速度、并发处理能力和数据管理的灵活性。

数据库分区是将一个大型数据库分解为多个逻辑部分，每个部分为一个分区。这种做法提高了数据库的可扩展性和可用性，使各个分区能独立管理和维护。

水平分区与垂直分区是两种主要的数据库分区方式，其区别在于数据的分割维度。水平分区聚焦于数据行的分割，而垂直分区则侧重于数据列的划分。

在处理数据量庞大的场景时，数据库分表成为一种有效手段，通过将大型表拆分为多个小型表，分表同样提升了数据库性能。然而，分表操作的复杂度相对较高，需要与业务逻辑紧密配合。

数据库分表的方式包括水平分表和垂直分表。水平分表是根据业务逻辑对数据行进行分割，垂直分表则是基于列的业务逻辑对数据进行划分。每种方式都旨在优化查询效率和并发处理能力，同时减少数据冲突和死锁的风险。

数据库分库则是将大型数据库划分为多个小型数据库，每个分库独立管理和维护，进一步提升了系统的可扩展性和可用性。垂直分库和水平分库是两种常见分库方式，它们分别适用于不同场景，例如垂直分库优化常见查询列，而水平分库适用于数据量巨大、单个节点无法承载的情况。

分库的实现通常需要考虑数据一致性、事务处理和数据分散策略。在实现水平分库时，分片键的选择尤为重要，以确保数据均匀分布于各个节点，并能有效处理数据一致性问题。

总结而言，数据库分区、分库和分表通过优化数据库系统的结构和操作流程，显着提升了性能与可靠性。它们适用于应对数据量快速增长的挑战，通过合理的设计与实施，能够显着提升大型数据库系统的整体表现。