[セコイア]データベースSequoiaDBセコイアテック|分散データベース千億特大のテーブルの最適化の実践

01

入門

加入者の増加、事業開発、データの量との業務・システムが増加し、パフォーマンスの問題の大企業ユーザーは、大規模なデータテーブルが実現するビジネス機能に大きな障害になります。その中でも、大きなテーブルの最も一般的なタイプのような水のテーブルには、パフォーマンスのボトルネックの企業ユーザーが頻繁に遭遇します。

このホワイトペーパーでは、パフォーマンス・チューニングに基づいて、大きなテーブルのように水に焦点を当てて大きなテーブルのセコイアデータベース記憶を探るSequoiaDB。SequoiaDBセコイア・データベース、新世代OLTPなどの分散データベースは、広く高い同時動作シナリオと大容量データ記憶装置に使用されます。ストレージおよびデータの膨大な量の高い同時動作のためには、従来のデータベースに比べて分散データベースは、自然の利点、パフォーマンスの問題特大のテーブルを解決するのは簡単な特徴のSequoiaDBデータベースジャイアントセコイア品種、の使用の合理化を持っています。

02

データストレージは、計画することが重要です

水テーブルの大きなクラスのために、予備的なデータ・ストレージ・プランニングは、より高いパフォーマンスとより効率的なデータサービスを提供するために、データベースクラスタのハードウェア・リソースの効率的な利用を計画して特に重要で、合理的なデータストレージです。

1. ハードウェア構成と規模クラスタ

計画データベースクラスタの開始時に、研究を通じてデータベースクラスタを徹底的に合理的なクラスタサイズだけでなく、サーバのCPU、メモリ、ハードディスク、ネットワークカードを評価するためのシステムおよび長期的なビジネス開発計画を配置し、サポートアプリケーションのスケールに必要。

データベースクラスタのサイズの正確な評価は、野心的で複雑な統合プロジェクトで、いくつかのビジネスをサポートする評価データのニーズを必要とします。ビジネスの急速に変化するニーズに起因する通常の状況下では、ビジネスの成長は、一般的に、より高い予想より小さなクラスター計画は、ビジネスの研究情報の1.5〜2倍に基づいて評価することが可能で、大規模なクラスター計画は1〜1.5倍で評価することができます。

クラスタサイズは、事業規模、データ・ストレージ・サイズ、3年間のデータフローテーブルの最大サイズ、情報の三種類によって評価する必要があります。事業規模は、時間分布を操作し、訪問するビジネス・ニーズからデータベース操作の様々なタイプの割合を調査し、最終的にはTPSを操作し、運用データの同時実行性のすべての種類の取引に来ます。

株価データを評価するためのデータの水の主要なカテゴリ、3年間の増分データの推定、行動研究へのデータのサイズスループットおよびその他の情報のためのスケールのデータ・ストレージ、そして最終的にディスクを取引推定TPSと組み合わせたクラスタデータストレージサイズ、データスループット、に来てIOPS。衝撃の小規模評価のデータベース情報テーブルのクラスタのサイズ、唯一全体のサイズ情報ニーズを評価するための基準として、例えば、クラスタ1000基になるテーブルを格納する必要が、0.1ギガバイト、100ギガバイトの全体的な必要性当たり平均して、この大きさTBのクラスタサイズの数百に無視することができます。

特定のIOPSとデータスループットに応じてバランスディスクまたはソリッド・ステート・ドライブを使用して、クラスタの大きさを確定するために格納する動作、各ディスクのサイズ、ハードディスク等のいくつかは、TPSによれば、サーバをマウントし、同時動作型の比CPUとメモリを構成するための度合い。一般に、CPUメモリが1の割合を推奨：8、1.5〜3Tの単一のハードディスク容量を主に、大きな単一のディスクIOパフォーマンスのボトルネックの容量は、代替的に、クラスタのサイズおよびクラスタのスループットに応じてギガビット・イーサネット・ネットワーク帯域幅を使用して、より容易に起こりますまたはギガビットネットワーク。

2.どのようにより良い水のテーブルを構築します

サービス時間ディメンションおよび自然キー寸法：クラス・データ・ストリームは、典型的には、二次元特徴を含みます。最も普通の水のテーブルのための多次元パーティションテーブル（図1）は、データの単一のセットが大きすぎに達しないことを確実にするために、テーブルの異なる部分集合に切断異なるビジネス日付によってマスタテーブル内のデータの最初のコレクションを作成することです;次いで、クラスタ内の各データノードに破壊自然キーデータによってサブテーブルのセットで、データの単一のセット内の1つのノード上のデータの量は、百万円未満のオーダーであることが好ましいです。また、多次元のビジネスは日付によって仕切られ、それがクラスタの横展開を非常に簡単に実装することができます。

。なお、水のテーブルスペースのデザインコレクション、コレクションスペースを作成するために、毎月最高の年次または、そのデータを迅速にバックアップすることができたときにデータの保存期間を超えていることを、削除でのストレージスペースを解放。

3.そして、適切な計画はありません一度、すべてのことができます

そして、合理的なデータ・ストレージ・プランニング、データや刻々と変化するビジネスニーズの急速な成長に直面して、とても無力に見えた、データの成長は常に期待を超えますが、パフォーマンスのボトルネックは、常にその日に起こっています。今回は、特定のパフォーマンスの問題のためにパフォーマンスを最適化する必要があります。

03

ハードウェアリソースのパフォーマンスのボトルネック分析

クラスタのハードウェアリソースの使用は、変更が変化するから、アイデアの分析を引き出すために、クラスタのビジネスの変化や業務の変化が起こる必要がある場合、ハードウェアリソースの使用状況の変化を通じて、あなたが視覚的に判断することができ、パフォーマンスのボトルネックを分析するための重要な基礎です。

データクラスタを監視1.ハードウェアリソースが基本であります

集群服务器各硬件资源的日常性能监控很重要，通过日常的监控数据，可以了解集群性能的波动情况。

nmon监控软件是是一款很出名的开源的系统性能监控工具，用于监控AIX\linux系统的资源消耗信息，并能把结果输出到文件中，然后通过nmon_analyser工具产生数据文件与图形化结果。如图2是nmon的运行主界面，互联网上有许多关于nmon工具的安装、实时监控、数据采集、分析报表生成等一整套教程，感兴趣的小伙伴可以了解一下。

 
2. 集群硬件资源使用情况多维度分析

硬件资源使用情况分析，分为实时监控分析和监控报表数据分析，两者需要需要结合使用。

对于常态化的性能问题，先使用实时监控获取具体进程使用的各硬件资源的情况，再结合报表分析将监控的时间长度拉长，找到出现性能变化的起点，看这种性能变化是否是周期性的、随机性的或是渐变的，结合此时点前后的生产变更情况以及相关数据操作动作来定位问题。

对于已发生暂时没有重现的性能问题，先通过监控报表分析手段，分析性能问题发生时点前后的硬件资源变化，再将监控的时间长度拉长，尝试找出资源变化的规律，然后通过应用日志、数据库日志和生产变更情况，找出引发性能问题的操作。最后，尝试重新执行相关操作，并进行实时性能监控，验证相关问题猜想。

从硬件资源监控中找出性能变化的内在逻辑是问题分析的关键所在，掌握硬件资源的变化规律就初步掌握了集群的性能情况，也是进行性能调优的第一步。

04

数据库集群业务情况与操作分析

掌握了解硬件资源性能情况是性能优化的第一步，还需要结合集群业务情况与各类操作比例与时间分布，才能进一步精确的定位性能问题。

1. 业务情况摸底

业务情况摸底一般通过业务访问监控接口持续获取业务访问情况，并结合业务逻辑分析需要执行的数据库操作，获得业务TPS、并发度、数据操作类型分布、数据吞吐量等信息，以此评估数据库集群压力。

2. 数据分布情况分析

数据分布不均导致的性能问题是一个非常常见的问题，流水类超大表出现数据分布不均主要是由于业务主键字段随机性弱，无法很好的进行哈希打散，可使用其他随机性较强的字段代替，或者结合数据特点使用范围分区也是一个可以尝试的方法。

如何确定数据是否均匀分布？首先，通过查看主表集合的编目信息，检查业务日期切分是否均衡；然后，查看每个子表集合的编目信息，检查数据是否根据业务主键打散到所在数据域的各个节点；最后，抽查2~3张子表集合，检查子表集合在每个节点的数据量是否相当均衡。

3. 访问计划分析

通过query.explain({ Detail : true, Run : true })可获取查询的详细访问计划。通过分析数据操作语句的访问计划，可以掌握该数据操作的涉及到哪些子表集合，每个子表集合的每个节点的访问计划情况，包括访问计划的扫描方式、索引使用情况，数据情况，资源使用情况等信息。

4. 查询监控与全表扫描检测

通过抓取数据库集群会话快照db.snapshot(SDB_SNAP_SESSIONS)，可以捕获每个查询的数据操作详细信息，包括会话状态、线程信息、索引数据信息、数据操作记录数、操作耗时、资源使用情况等等信息。

可通过不断抓取会话快照信息，监控会话快照信息中的"LastOpInfo"字段是否包含"tbscan"字样，来检测数据操作中是否存在全表扫描的情况。

05

性能优化指引

流水类超大表的性能优化，一般遵循从操作到软件再到硬件，由简到繁的一个优化思路，优化前需要充分了解软硬件情况，例如数据操作情况、数据库配置、系统性能情况等等。

1. 适量创建高效索引

索引是一种提高数据访问效率的特殊对象。恰当的使用索引可提高数据检索效率，但索引使用不当反而会降低数据检索速度，严重的还会造成数据库整体服务性能下降。

利用索引对流水类超大表进行性能调优，是最为经济、简单、高效的一种方式。那么，如何恰到好处的创建索引，即能提高数据操作效率，又不会对数据库服务性能造成影响？

首先，需要了解索引的可供调优参考的部分特性，以及相关性能开销成本。

部分相关特性：

使用二分查找，可快速定位数据，平均复杂度是O(logN)。

索引数据信息大小远小于表数据大小，索引数据可长时间缓存在内存。

使用B树结构，三层的B树可以表示上百万的数据，通过索引检索数据可减少磁盘I/O次数，数据字段越小索引效率越好。

I/O的次数取决于B树的高度H，假设当前数据表的数据为N，每个磁盘块的数据项的数量是M，则有：H=log(M+1)N，当数据量N一定的情况下，M越大，H越小；而M=磁盘块大小/数据项大小，磁盘块大小也就是一个数据页的大小，是固定的，如果数据项占的空间越小，数据项的数量越多，树的高度也就越低。这也就是为什么每个数据项，即索引字段要尽量的小，比如int占4个字节，要比bigint的8个字节小一半。这也是为什么B树要求把真实数据放在叶子节点内而不是内层节点内，一旦放到内层节点内，磁盘块的数据项会大幅度的下降，导致树层级的增高。当数据项为1时，B树会退化成线性表。

索引具有最左匹配特性，创建复合索引要根据数据重复率和查询使用的字段情况进行创建。

B树的数据项是复合性数据结构，按照从左到右的顺序来建立搜索树的，例如：当（小张，22，女）这样的数据来检索的时候，B树会优先比较name来确定下一步的搜索方向，如果name相同再依次比较age和gender，最后得到检索的数据。但是，当（22，女）这样没有name的数据来的时候，B树就不知道下一步该查哪个节点，因为建立搜索树的时候，name就是第一个比较因子，必须根据name来搜索才知道下一步去哪里查询。比如，当（小张，男）这样的数据来检索时，B树就可以根据name来指定搜索方向，但下一字段age缺失，所以只能把名字是“小张”的所有数据都找到，然后再匹配性别是“男”的数据了。

索引数据是有序的，支持顺、逆排序，合理利用可优化查询排序和分组效率。

数据重复率越低索引使用效率越高。

相关性能开销：

对数据操作都需要额外对索引进行维护，索引越多维护性能开销越大。

创建索引需要排序，需要额外存储空间，会获取表锁，创建时会消耗大量内存、CPU。

一次数据查询操作，至少产生2次IO操作，一次查询索引数据，一次访问表数据。

一次数据插入操作，至少产生1+n（n为索引个数）次IO操作，当索引当叶结点过满时会触发结点递归分裂时，IO操作会剧增。

一次数据删除操作，至少产生3+n（n为索引个数）次IO操作，当索引当叶结点过空时会触发结点递归合并时，IO操作会剧增。

一次数据更新操作，如果更新字段不是索引字段，则产生3次IO操作，如果更新字段为索引字段，则产生3+n（n为索引个数）次IO操作，且索引结点的分裂与合并均有可能发生（变长数据类型字段）。

掌握了索引相关特性和性能开销，结合流水类超大表的特点，通过评估确定数据插入、更新和查询操作的比例，调研更新字段与查询字段是否有重合等信息，以此来确定是否需要创建索引，创建哪些索引。

一般来说，流水类超大表都需要创建流水主键索引，以确保流水数据唯一性。其他的索引创建需要可根据更新、查询条件、数据规模等信息进行评估，通常创建2~3个索引效率性能比较为理想。如果数据查询操作为主，可酌情增加索引数量。对于多个字段组成的查询条件，可根据条件字段的重复率情况创建复合索引；对于有数据排序、数据分组的字段，可按排序分组字段创建复合索引。

2. 优化查询语句

对于流水类超大表的查询优化，有两个基本原则：一是通过索引调优，强制数据查询走指定索引，二是通过限制查询的业务日期范围，减少查询检索的数据规模。

索引调优可以结合本文 “适量创建高效索引”章节所述合理创建索引，并通过查看执行计划确保查询走索引。

合理的利用巨杉数据库主子表的特点，在查询时确定查询数据的业务日期维度，可以极大的减少检索数据规模，减少节省数据库集群资源，举个例子：应用需要通过流水号（主键）查询该流水号对应的流水数据，该流水号记有业务日期信息。通常情况下，简单的使用流水号就可以准确快速的查询到该条流水，但对于一个流水类超大表来说，可能存放着十年几十年的流水数据，数据可能存储在上百张子表中，如果单单使用流水号查询，那么数据库就需要对每个子表进行一次索引检索，最后只会有一张表检索到数据，但如果把流水号中的业务日期截取出来作为一个查询条件，那么数据库就可以通过主表的业务日期分区信息定位到该流水数据所在的子表，数据库仅会对该子表进行索引检索。

另外，对于对大范围业务日期查询，且需要分页处理的，可每次查询一个业务日期分区，分多次完成查询。对于查询数据结果集很大的查询，通常使用分页查询，单页数据量在数百以内为佳。

总的来说，查询语句的调优没有一套固定标准的操作方法，它是一个循序渐进的过程，只有通过不断的测试、优化、再测试、再优化，在不断迭代中逐步提高查询效率。

3. 调整数据切分粒度

流水类超大表什么时候需要调整数据切分粒度，可能是本节内容的最大挑战，需要综合考虑集群硬件资源使用情况、查询优化情况，子表单节点数据大小、索引大小等等一系列问题。

从硬件资源使用角度考虑，硬盘使用率在70%以下，超过70%可以考虑直接进行集群扩容，在集群CPU、内存基本保持在60%以下，只有IOPS居高不下，且IO读紧张IO写正常，查询业务TPS远低于IOPS，此现象说明1次查询会产生非常多的IO读；从查询优化情况看，已无全表扫描的查询，查询语句已做了足够的优化，但查询依然无法满足需求；以单子表单个节点的数据规模进行评估，数据规模需要控制在百万级别，单条数据记录的字段数与数据长度对数据检索也有影响，特别是数据更新操作，数据字段越多、数据长度越长更新效率越低；评估查询语句中的业务日期范围，查询越精确，切分粒度的调整弹性就越大；另外，根据创建的索引的字段类型以及实际索引大小，评估索引是否可以完全缓存至内存，尽可能将数据切分粒度调整至索引数据可完全缓存至内存。

实际上，调整流水类超大表的数据切分粒度，就是提高数据并发度，减少单子表在单节点的索引数据规模，使得整个索引数据可以常驻内存，最大程度减少IO开销，故而，调整数据切分粒度会增加内存、CPU资源的消耗。

如何调整数据切分粒度是需要探讨的另一个问题，对于按本文介绍的主子表建表规则创建流水类超大表，很简单的就可以完成调整动作，只需要将主表的每个业务日期区间，拆分成多个切分区间，即一个子表数据拆分成多个子表。关键的问题是，拆成多少个子表合理，一般建议一个子表拆分成2~3个子表较为合理，不过，最可靠的方式是——模拟生产测试。

4. 升级短板硬件

服务器停机升级短板硬件，对于天然具备容灾高可用特性的巨杉数据库来说，是一件不能再简单的事情，只需将需要升级的服务器的数据库主节点切换到其他服务器，就可以停掉数据库服务然后进行停机升级；如果是替换硬盘，在重启完成新硬盘挂载并创建相应数据目录后，重启数据库服务后，数据库会自动同步数据。

通过硬件资源的性能瓶颈分析，可以很清晰的看出硬件资源瓶颈，可根据业务需要酌情升级短板硬件，如添加内存条，将磁盘替换成固态硬盘，甚至可直接将整台服务器置换掉。

5. 集群扩容

データベースクラスタが不足収納スペースで、または上記の最適化方法がうまく解決のパフォーマンスのボトルネックでないときは、クラスター展開を進めることができます。

クラスター展開は、既存のクラスタに応じて調整し、最適化する必要がある場合、例えば、元のデータフィールドは、3台のサーバを有するサージインクリメンタルデータので、後続のデータフィールドのプログラミングは、6台の以上のサーバを必要とします。別の例として、古いサーバーのハードウェアリソースの使用量に新しいサーバー参照が、必要性は、ハードウェア構成を調整するアイドル構成要件を減らし、コンフィギュレーションショートボードのハードウェアリソースを改善し、というようにします。準備ができて、参照オブジェクトのおかげで、ハードウェア構成の評価及び評価の規模のクラスター展開は非常に簡単することができます。

大きなクラスクラスタの拡張オペレーティング水テーブルは非常にシンプルであるために、ちょうど新しい仕様データノードによってサーバーのデータベースソフトウェアの巨大セコイアの良いをインストールし、新しいノードは、元のクラスタに、新たなデータフィールドとして追加した後、さ後続の操作新しいデータフィールドのサブテーブル作成日セット、セットがメインテーブルに装着された仕様に基づいて、テーブルの、サブセットは、すべてのステップは、これまでクラスター展開を完了しました。データフィールドは、ハードウェア資源の様々なタイプを使用するのに十分でない場合、以下に示すように、2030年以降のデータフィールド2つの格納フローデータを追加してもよいです。

 

06

概要

大きなテーブルのような水のパフォーマンスの最適化は、継続的な反復プロセスは、データベースクラスタ、データ層へのビジネス層に確立する必要がある、ハードウェアリソース層は、完全なハードウェア資源解析のターンの理解、クラスタ操作分析と検出の基礎を持っています、ビジネス分析は、パフォーマンスの問題の配置を完了します。

一方、データベースジャイアントセコイアのユーザーのために、大きなテーブルの最適化問題を扱うとき、SequoiaDBセコイア多次元データベース・パーティショニング機能と簡単にスケールアウトメカニズムの使用の合理化は、簡単な顔でパフォーマンスの問題に大きなテーブルを解決するために、その後、大きなテーブルのパフォーマンスを最適化心配しないでください -