思考とMySQLデータベースサブ分割とパーティションテーブルとの間の差

A. Skelter

　　私は何度も、技術が同じであることを一つの技術に固執していないと述べました。それはアイデアが最も重要であり、重要なプログラミングのアイデアです。大量のデータは、必要性がポイントを考えたときに結晶粒径を微細化します。データの量があまりにも断片化されている場合、必要が荒い粒度にフィットすると思っています。

1.1ポイント

　　多くは、これらのいくつかの例がポイントと考えられている。ここ,?アイデアポイントのプログラミング技術を使用しています

• 分散型サービスの開発に集中サービス
• ？1.7ConcurrentHashMapにCollections.synchronizedMap（x）は、その後1.8ConcurrentHashMap、洗練ロックの粒度からしばらく、まだ保証スレッドの安全性
• AtomicIntegerからLongAdderに、ConcurrentHashMapのサイズ（）メソッド。分散液は、数を蓄積するマルチスレッド高め、CASの数を減少させると考え
• JVMのG1 GCアルゴリズム、ヒープがメモリ管理に多くの地域に分かれています
• リージョンサーバーのHBaseの、複数の領域に管理データ
• 開発は通常、スレッドプールのリソースが分離されていません

2.2適切な

　　多くの技術は、一緒にプログラミングのアイデアに適用され、ここでいくつかの例では、これらは一緒にアイデアです

• TLAB（地方交付バッファスレッド）、ローカル配布キャッシュを通します。マルチスレッドの競合を避けるため、物流の効率化目標を改善
• ヒープに行くことなく、分析、直接スタックに割り当てられたメモリの変数インスタンス化を脱出、スレッドスタックスペースの終わりが回収されます。ヒープ割り当てられたオブジェクトの量の一時的な削減
• CMS GCアルゴリズムの下では、ラベルの使用がクリアするが、しかしそこには、メモリの断片化のサポートを統合するように構成されています。以下のような：-XX：UseCMS-CompactAtFullCollection（仕上げFullGC、ストップザ・ワールドが長くなるかどうか）と-XX：CMSFullGCs-BeforeCompaction（FullGCを終えた後、数回の圧縮）
• JITは、連続した一連の操作を繰り返してロックを見つけ、同じオブジェクトのロックを解除する際に、粗大ロックは、ロック同期の範囲を拡大します
• カフカネットワークデータ伝送は、ネットワークのオーバーヘッドを低減する、いくつかのデータ構成を有しています。以下のような：などbatch.sizeとlinger.ms
• 開発は、通常、バッチインターフェースを取得していないと呼ばれています

II。パーティション

　　すべての紙ベースのMySQLのInnoDB

　　：ブロガーはブログのMySQLのパーティションを書いた前にそうそこに、書き込みに少し余分なインクで具体的な表示されませんので、最初のパーティションを述べ、その後、身体を言うことを言ってhttps://www.cnblogs.com/GrimMjxを/p/10526821.html

2.1実装

　　彼らは、書き込みにそこに上記のリンクを実装する方法、テーブルの主キーまたは一意のインデックスが存在は、パーティション化列が一意のインデックスの不可欠な部分でなければならない場合は、単に場所を覚えておいてください。

　　これは、ポイントデータベース、透明アプリケーション、何も変更することなくコードです。

2.2内部文書

　　あなたは、ディレクトリの場所がわからない場合は、データディレクトリに移動し実行することができます。

 　　次に、ファイルの中身を見て：

 

　　私たちは、ファイル、ドキュメント、および.FRMファイルの2種類があり、図から見ることができるの.ibd

• .FRMファイル：ファイルのテーブル構造
• .ibdファイル:? InnoDBは、データとインデックスファイルは、（あなたの結果は、.MYD .MYIインデックスファイルやデータファイルを実行することができる、それが問題で、これはMyISAMストレージエンジンではありません同じ.ibdataであり、InnoDBのファイルがの.ibdに対応します）。注文この表は、5つの領域に分け、その5つのそのような文書が存在しているので、
• .PARファイル：あなたは結果、そこによく、またはしない場合があり.PARファイル。注：MySQLは5.7.6以降では、もはや作成していない .PARパーティション定義ファイルを。内部ディクショナリに格納されているパーティションの定義データ。

2.3データ処理

　　パーティションテーブルの後のMySQLのパフォーマンスを向上させます。テーブル場合は、それが唯一の.ibdファイル、大B +ツリーです。部品表場合、ゾーニング規則は小さい木の複数に、すなわちAより大きいB +木、異なるゾーンに分割されます。

　　（PS：あなたは、クラスタ化インデックスのB +ツリーを勉強したい場合は、データの行数を入れて見ることができます：https://www.cnblogs.com/GrimMjx/p/10540263.html）

　　、効率を高め、確かに読んでクラスタ化インデックスのB +ツリーの対応するパーティションを歩いて、あなたが分割キーインデクスを取る場合は、セカンダリインデックスのB +ツリーの対応するパーティションを行きます。

　　あなたは、パーティション・キーを取らない場合は、すべてのパーティションの意志一度実行されます。複数の論理IO原因！あなたが説明することができ、通常の開発、SQL文のパーティションのクエリを見たい場合はpartitonsはXXXXX文を選択します。私たちは、SELECT文が複数のパーティションを残して見ることができます。 

MySQLの>パーティションを説明選択 TxnListどこのstartTime>から* 「2016年8月25日夜十二時00分00秒」とのstartTime < 「2016年8月25日夜11時59分00秒」;  
+ ---- + ------------- + ------------------- + ---------- - + ------ + --------------- + ------ + --------- + ------ + ------- + ------------- +   
| ID | SELECT_TYPE | 表| パーティション| タイプ| possible_keys | キー| key_lenに| REF | 行| エクストラ|  
+ ---- + ------------- + ------------------- + ---------- - + ------ + --------------- + ------ + --------- + ------ + ------- + ------------- +   
|  1 | SIMPLE | ClientActionTrack | p20160825 | ALL | NULL | NULL | NULL | NULL |33868 | どこ使い方|  
+ ---- + ------------- + ------------------- + ---------- - + ------ + --------------- + ------ + --------- + ------ + ------- + ------------- +   
行にセット（0.00秒）

III。サブライブラリーサブテーブル

　　場合は、時間とのビジネスを超える表は、データの量がますます大規模なライブラリのテーブルになります。データ操作も成長します。最終的にデータ量を運ぶ物理マシンの限られたリソースは、機能を処理するデータが限られています。この時間は、それはスタンドアローン収まらない、超大型テーブルの種類に着手するサブライブラリーサブテーブルを使用します。

　　パーティションは通常、時間のレンジ・パーティション化、容易なアーカイブのより多くのと、スタンドアローンに置かれ、パーティションと異なっています。しかし、サブライブラリーのサブテーブルのコードを実装する必要があり、内部のmysqlパーティションが達成されます。サブライブラリーサブテーブルとパーティションは矛盾しない、それを組み合わせて使用​​することができます。

3.1を実現します

3.1.1サブライブラリーサブテーブルの標準

• ストレージ占有100G +
• 日次増分データ200ワット+
• 億の単一表の番号+

3.1.2サブライブラリーのサブテーブルのフィールド

　　サブライブラリーのサブテーブルのフィールドの値が非常に重要です

1. ほとんどのシーンでは、フィールドは、問い合わせのフィールドです
2. 数値

　　一般的な使用useridは、上記の条件を満たすことができます

3.2分散データベースミドルウェア

　　2種類、プロキシとクライアントアーキテクチャに分かれて分散データベースミドルウェア。プロキシモードはMyCat、DBProxy他のクライアントアーキテクチャは次のようにTDDL、シャーディング-JDBCを持っていました。だから、どのような違い、それはプロキシとクライアントアーキテクチャを作るのですか？何がこれのそれぞれが長所と短所を持っているのですか？実際には、マップを見て知ることができます。

　　プロキシモードは、update文がエージェントに送信され、その後、我々は選択して、エージェントは、特定の基礎となるデータベースによって運営されています。それは、そうでなければ、データベースのダウンタイムはありません、それ自体が高可用性を確保する必要があるエージェントを必要としなければならない、プロキシは、その後離れて歩いた、ハングアップ。

　　客户端模式通常在连接池上做了一层封装，内部与不同的库连接，sql交给smart-client进行处理。通常仅支持一种语言，如果其他语言要使用，需要开发多语言客户端。

　　

　　各自的优缺点如下： 

3.3 内部文件

　　找了一个分库分表+分区的例子，基本上和分区表的差不多，只是多了多了很多表的.ibd文件，上面有文件的解释：

[miaojiaxing@Grim testmydata]# ls | grep 'base_info'
base_info_00.frm
base_info_00#P#p_2018.ibd
base_info_00#P#p_2019.ibd
base_info_00#P#p_2020.ibd
base_info_00#P#p_2021.ibd
base_info_00#P#p_init.ibd
base_info_00#P#p_max.ibd
base_info_01.frm
base_info_01#P#p_2018.ibd
base_info_01#P#p_2019.ibd
base_info_01#P#p_2020.ibd
base_info_01#P#p_2021.ibd
base_info_01#P#p_init.ibd
base_info_01#P#p_max.ibd
base_info.frm
base_info.ibd

3.4 问题

3.4.1 事务问题

　　既然分库分表了，那么肯定涉及到分布式事务，如何保证插入到不同库的多条记录能够要么同时成功，要么同时失败。有些同学可能想到XA，XA性能差而且不需要使用mysql5.7。柔性事务是目前主流的方案，TCC模式就属于柔性事务。

　　对于分布式事务问题每家公司有自己的实现，华为用saga，阿里用TXC，蚂蚁用DTX，支持FMT模式和TCC模式。

3.4.2 join问题

　　tddl、MyCAT等都支持跨分片join。但是尽力避免跨库join，比如通过字段冗余的方式等。

　　如果出现了这种情况且中间件支持分片join，那么可以这样使用。如果不支持可以手工查询。

四.总结

　　分表和在用途上不一样，分表是为了承接超大规模的表，单机放不下那种。分区的话则一般都是放在单机里的，用的比较多的是时间范围分区，方便归档。性能稳定上的话都是一个个子表，差不多，区别应该是分区表是mysql内部实现的，会比分表方案少一点数据交互