「データ集約型アプリケーション、」研究ノート

それは再びそれを読んで、本当に良い本のクレソン10.0である「設計データ集約型アプリケーション」、約半分の時間がかかりました。

その上のデータストレージ、データ処理のMySQL、Redisの、Solrの、MongoDBは、Elasticsearch、カフカ、ハイブ、HBaseの、スパーク、FLINK、MapReduceの、のNeo4j、タイタン、InfiniteGraphとのほぼすべての構成要素を説明する本の著者。むしろ、データベース、キュー、NoSQLの、バッチ処理、ストリーミングコンポーネント、事実上すべてのタイプをカバー内部の著書、「ポインティング国、情熱的なキャラクター、汚れ侯百万年」感じで。

この本は、直面しているデータモデルと遷移図をリレーショナルデータモデルへの文書データモデルから問題を説明し、分散システムの中核問題を説明、対処することができ、ストリーミングにビジネスシナリオのバッチを導入しました。本はあまりにも野心的な技術的なポイントをカバーしているのでもちろん、ポイントの様々な部品の特性や機能は、よりマクロレベルに立って詳細に一つ一つを導入していないが、個々の部品の特性を説明し、ビジネスシナリオをカバーすることができます。

私は本を​​読んで感動した以下の点があります。

1データモデル

本书介绍了文档型数据库,关系型数据库,图数据库。 文档型数据库的schemaless, 典型的就是Mongodb和Elasticsearch; 关系型数据库不必说了,应用最广泛的MySQL; 图数据库用得比较少,Neo4j算是典型了。 通过从文档到图,从无关联到处处关联。让Mongodb, Elasticsearch, MySQL, Neo4j在我的知识体系中不再是孤立的点,而是有内在联系的知识链条。

データベースの2シェルバージョン

作者通过一个基于shell实现的数据库,讲解索引。 从Hash索引到树索引, 从B tree到 LSM tree。Hash索引无法解决区间查询的问题, 二叉树面对硬盘索引读取性能问题, B Tree的写入性能问题...  估计读完本书后,我一度陷入困惑,应该是希望更深入探索索引细节的想法和原定计划的冲突。

MapReduceのの3シェルバージョン

作者通过组合cat, awk, sort, uniq, head 几个简单的命令分析日志,让后讲解mapreduce。 这个切入点相当经典, 比mapreduce的word-count有意思多了。

分散システムの4一貫

作者讲解了分布式系统存在的问题,主要是一致性问题。 然后引出选举算法的核心: 共识。相当精辟。 可惜分布式算法的细节我一向敬而远之,觉得这个坑有点深,不急着入坑。

あまりにも多くの明るいスポットは、おそらく、この本を見て、システムの詳細の一部を理解するために、収穫はより多くの異なるものになります。

文脈上明確です:

信頼性、拡張性、保守性:システムは、次の3つの質問に直面しなければなりません。その後、3つのコア・ポイントに基づいて、データ集約型のアプリケーションがこれらの3つの目標を達成する方法を説明します。

データ・モデル・レベルから、SQLなどのアクセス方法の統一抽象。
モデルベース設計、さまざまなインデックス、システムの保証性能を実現します。
ネットワーク伝送レベル、データ符号化の種々の設計は、使用および性能の競合やすさのバランスをとります。

単一ノードは、拡張システムのコピーによって、同時実行のビジネスニーズを満たすことができないとき。ここでは整合性の問題は、すでに登場します。
単一のストレージノードは、フラグメント拡張システムによるサービス要件を満たすことができない場合、ストレージ、いずれかの容量や性能のボトルネックのボトルネックを解決します。
アトミックトランザクション機構による一貫性のないデータの問題を解決するために、次のことを確認します。
これは、分散システムの問題を解決するために、トラブルとアルゴリズムのすべての種類を示しています。

最後に、得られたデータ、およびストリーミングは、バッチプロセスを説明します。

データ処理コンポーネントに作者相当パノラマを描きました。だから、多くのデータ・コンポーネントの開発システムアーキテクチャの選択はまた、偉大なテストをやってます。類似点とさまざまなコンポーネントの違いを理解することが幸いなこと、類推によって学ぶことができ、アナロジーは良いです。

おすすめ

転載: blog.51cto.com/sbp810050504/2406541