MySQLが適切に使用され、なぜESをオンにする必要がありますか？
http：// developer.51cto.com/art/201911/605288.htm
10億件のドキュメント、一日平均クエリに到達するために強力な検索エンジン、ほぼリアルタイムストレージのサポート、検索データは、システム内Jingdongはホームの受注に大きな役割を果たしているとして、データの量は、現在保存されているESの受注、分散センタークラスターをElasticsearch 5億。
- 著者：匿名ソース： 今日のニュースの見出し | 2019年11月1日15：50
Jingdongはそれが外部のビジネス・ツー・オーダーであるかどうかを受注センターのホームシステム事業、あるいは内部下流のシステムに依存しているが、受注照会コールの量が少なく受注のデータの読み書きが得られ、非常に大きいです。
我々は、MySQLに格納されたデータを注文するが、どうやらのみクエリの大きな数をサポートするためには、DBによっては望ましくありません。一方で、いくつかの複雑なクエリのために、MySQLのサポートが十分に友好的だったので、システムは、主要な圧力注文のクエリをホストするElasticsearch注文センターを使用しています。
10億件のドキュメント、一日平均クエリに到達するために強力な検索エンジン、ほぼリアルタイムストレージのサポート、検索データは、システム内Jingdongはホームの受注に大きな役割を果たしているとして、データの量は、現在保存されているESの受注、分散センタークラスターをElasticsearch 5億。
近年のJingdongのホーム、ビジネスの急速な発展に伴い、受注センターESは、プログラムはまた、これまで、ESクラスタの開発を進化さ設定もES読み書きをクラスタの安定性を保護し、リアルタイムの相互支援スキームを設定することです、次を与えましたこのピットの歴史の一部をご紹介して遭遇しました。
道路のESクラスタアーキテクチャの進化
1、初期段階
一枚の紙、セットアップするための基本的にノープランとして受注センターESの初期の段階では、多くの構成は、クラスタのデフォルト設定を維持しています。グループ全体の弾性クラウド上に展開クラスタ、クラスタノード、およびマシンの展開ESは混乱しています。同時に、クラスタの大きさに応じて、クラスタは明らかにビジネスセンターも許可されていない注文のために、単一のポイントESの問題を持っています。
クラスタ段階から単離された2
そして、途中混合布などの事業の多くは、ESクラスタを使用しました。しかし、オーダーセンターにESは受注センターESサービス例外につながるオンライン注文、多くのリソースを先取りします時折混合布のクラスタシステムを、保存されています。
この場合、第1の弾性クラウドES注文中心が高いクラスタノードをつかむために、それらのシステム・リソースの外に移動するように、配置されているので、明らかに注文照会の安定性への影響は、耐え難いされ、クラスタの状態はESわずかに改善しました。しかし、クラスタデータの増加に伴って、弾性クラウド構成は、ESクラスタを満たすことがより少なくできており、物理的な分離、単に物理マシンのハイプロファイルの中心にESクラスタを展開する最終的な注文を完了するために、ESクラスタのパフォーマンスが改善されています。
3、ノードのコピーがステージを調整します
ESクラスタが別の物理マシンを展開するための素晴らしい関係のハードウェアリソースを持つESのパフォーマンスは、クラスタの内部ノードは、全体の物理マシンのリソースを占有されていない、まだクラスタノードが同じ物理マシン上で実行されているリソースが押収されます質問。したがって、この場合には、順番に単一の物理マシン上に展開され、各ノードのESを使用して、単一ノードはマシンリソースのESの最大の度合いを使用することができるようにします。
しかし、その後、再び質問、それの単一ノードのボトルネックであれば？どのように我々はそれを最適化する必要がありますか？
ESクエリ原理、ノードに対応する各スライスの数の負荷にないスライスタイプ（嗜好パラメータ）がクエリ要求場合、要求は、フラグメント番号を打ちます。デフォルトの設定のクラスタコピーがメインの一つであり、対応する物理マシンを向上させながら、このような場合のために、我々は拡張コピーモードを考えて、メイン1のデフォルトは、メイン2になります。
概略的なES建て注文センタークラスター
示されているように、全体が外部要求に均衡VIPロードを経由してセットアップします。
ゲートウェイノード上の要求を転送する主クラスタ断片、サブスライスの二組（プライマリ2）のセット全体は、ヒット・ノードの前にポーリングデータにより等化されるであろう。クラスタ増加し、全体的なクエリのパフォーマンスクラスタを高めるために、クラスタのスループットを向上させるための機械方法の拡張のコピー。
イラスト、グラフィック性能注文センターESクラスタのさまざまな段階を示し、視覚的な表現が大幅に最適化ESの各段階の後に、クラスタのパフォーマンスを向上させます：
もちろん、スライスの数や部数をスライスは、この段階では、可能ではない、我々はフラグメントの適切な数を選択するのさらなる調査を行いました。単一のクエリIDとページングクエリ：フラグメントの数は、サブライブラリーサブテーブル内のMySQL、および2つのカテゴリに分かれて現在の照会注文センターESとして理解することができます。
断片のより大きな数、クラスタのサイズが大きい横拡張され、特定のオーダーIDクエリフラグメンテーションに従っても大幅ルーティングを向上させることができるが、重合は、ページングクエリのパフォーマンスを低下させる、スライスの数が少ない、横膨張もクラスターサイズ小さい、単一のID、クエリのパフォーマンスが低下しますが、パフォーマンスは改ページクエリが増加します。
所以如何均衡分片数量和现有查询业务，我们做了很多次调整压测，最终选择了集群性能较好的分片数。
4、主从集群调整阶段
到此，订单中心的ES集群已经初具规模，但由于订单中心业务时效性要求高，对ES查询稳定性要求也高，如果集群中有节点发生异常，查询服务会受到影响，从而影响到整个订单生产流程。很明显这种异常情况是致命的，所以为了应对这种情况，我们初步设想是增加一个备用集群，当主集群发生异常时，可以实时的将查询流量降级到备用集群。
那备用集群应该怎么来搭？主备之间数据如何同步？备用集群应该存储什么样的数据？
考虑到ES集群暂时没有很好的主备方案，同时为了更好地控制ES数据写入，我们采用业务双写的方式来搭设主备集群。每次业务操作需要写入ES数据时，同步写入主集群数据，然后异步写入备集群数据。同时由于大部分ES查询的流量都来源于近几天的订单，且订单中心数据库数据已有一套归档机制，将指定天数之前已经关闭的订单转移到历史订单库。
所以归档机制中增加删除备集群文档的逻辑，让新搭建的备集群存储的订单数据与订单中心线上数据库中的数据量保持一致。同时使用ZK在查询服务中做了流量控制开关，保证查询流量能够实时降级到备集群。在此，订单中心主从集群完成，ES查询服务稳定性大大提升。
5、现今：实时互备双集群阶段
期间由于主集群ES版本是较低的1.7，而现今ES稳定版本都已经迭代到6.x，新版本的ES不仅性能方面优化很大，更提供了一些新的好用的功能，所以我们对主集群进行了一次版本升级，直接从原来的1.7升级到6.x版本。
集群升级的过程繁琐而漫长，不但需要保证线上业务无任何影响，平滑无感知升级，同时由于ES集群暂不支持从1.7到6.x跨越多个版本的数据迁移，所以需要通过重建索引的方式来升级主集群，具体升级过程就不在此赘述了。
主集群升级的时候必不可免地会发生不可用的情况，但对于订单中心ES查询服务，这种情况是不允许的。所以在升级的阶段中，备集群暂时顶上充当主集群，来支撑所有的线上ES查询，保证升级过程不影响正常线上服务。同时针对于线上业务，我们对两个集群做了重新的规划定义，承担的线上查询流量也做了重新的划分。
备集群存储的是线上近几天的热点数据，数据规模远小于主集群，大约是主集群文档数的十分之一。集群数据量小，在相同的集群部署规模下，备集群的性能要优于主集群。
然而在线上真实场景中，线上大部分查询流量也来源于热点数据，所以用备集群来承载这些热点数据的查询，而备集群也慢慢演变成一个热数据集群。之前的主集群存储的是全量数据，用该集群来支撑剩余较小部分的查询流量，这部分查询主要是需要搜索全量订单的特殊场景查询以及订单中心系统内部查询等，而主集群也慢慢演变成一个冷数据集群。
同时备集群增加一键降级到主集群的功能，两个集群地位同等重要，但都可以各自降级到另一个集群。双写策略也优化为：假设有AB集群，正常同步方式写主（A集群）异步方式写备（B集群）。A集群发生异常时，同步写B集群（主），异步写A集群（备）。
ES 订单数据的同步方案
MySQL数据同步到ES中，大致总结可以分为两种方案：
- 方案1：监听MySQL的Binlog，分析Binlog将数据同步到ES集群中。
- 方案2：直接通过ES API将数据写入到ES集群中。
考虑到订单系统ES服务的业务特殊性，对于订单数据的实时性较高，显然监听Binlog的方式相当于异步同步，有可能会产生较大的延时性。且方案1实质上跟方案2类似，但又引入了新的系统，维护成本也增高。所以订单中心ES采用了直接通过ES API写入订单数据的方式，该方式简洁灵活，能够很好的满足订单中心数据同步到ES的需求。
由于ES订单数据的同步采用的是在业务中写入的方式，当新建或更新文档发生异常时，如果重试势必会影响业务正常操作的响应时间。
所以每次业务操作只更新一次ES，如果发生错误或者异常，在数据库中插入一条补救任务，有Worker任务会实时地扫这些数据，以数据库订单数据为基准来再次更新ES数据。通过此种补偿机制，来保证ES数据与数据库订单数据的最终一致性。
遇到的一些坑
1、实时性要求高的查询走DB
对于ES写入机制的有了解的同学可能会知道，新增的文档会被收集到Indexing Buffer，然后写入到文件系统缓存中，到了文件系统缓存中就可以像其他的文件一样被索引到。
然而默认情况文档从Indexing Buffer到文件系统缓存（即Refresh操作）是每秒分片自动刷新，所以这就是我们说ES是近实时搜索而非实时的原因：文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。
当前订单系统ES采用的是默认Refresh配置，故对于那些订单数据实时性比较高的业务，直接走数据库查询，保证数据的准确性。
2、避免深分页查询
ES集群的分页查询支持from和size参数，查询的时候，每个分片必须构造一个长度为from+size的优先队列，然后回传到网关节点，网关节点再对这些优先队列进行排序找到正确的size个文档。
假设在一个有6个主分片的索引中，from为10000，size为10，每个分片必须产生10010个结果，在网关节点中汇聚合并60060个结果，最终找到符合要求的10个文档。
由此可见，当from足够大的时候，就算不发生OOM，也会影响到CPU和带宽等，从而影响到整个集群的性能。所以应该避免深分页查询，尽量不去使用。
3、FieldData与Doc Values
FieldData
线上查询出现偶尔超时的情况，通过调试查询语句，定位到是跟排序有关系。排序在es1.x版本使用的是FieldData结构，FieldData占用的是JVM Heap内存，JVM内存是有限，对于FieldData Cache会设定一个阈值。
スペースが不足している場合は、新しいFieldDataキャッシュを搭載しながら、LRU（Least Recently Used）アルゴリズムは、FieldDataを削除使用し、ロードプロセスは、システムリソースを消費し、素晴らしい時間がかかります。クエリの応答時間で結果は急上昇し、さらには、クラスタ全体のパフォーマンスに影響を与えます。この問題に対応して、解決策は、ドキュメントの値を使用することです。
ドク値
DOC値式の列のデータ記憶構造は、FieldDataと類似しているが、その位置は、ファイルのLuceneに格納されている、すなわち、JVMヒープを取りません。反復のESのバージョンでは、ドキュメントの値は、デフォルト設定から2.xでドク値FieldDataよりも安定です。
概要
高速反復アーキテクチャからこそ、近年の急速な発展により、ビジネスの急速な発展から茎、在宅ビジネス、順番中心のアーキテクチャ常にアップグレードしています。インフラプログラムは注文のみ、私は数年と信じて、最も適切な中心のアーキテクチャは、他の顔が、より高いスループット、より優れた性能、高い安定性となり、注文が中央システムになり、最高ではありません永遠の追求。