こんにちは これは、「著者による」 タランチュラの新しいバージョンに関する投稿です。 インターネットは楽しく配置されています。タランチュラについて見ると、2011年のバージョン1.3の記事があります。 そして、ある種のパンチ、それはそうです。 ボードフォーラムでは、一般に濃霧が発生します。 タランチュラ「まあ、それは大根のようなものだけだ」...
あるいは、最近トースターで誰かが「ソフィアはタランチュラのような追加専用のリポジトリである」と書いた自分自身のために発見をしました。 そのような投稿で、私はすぐに「made with us」ウェブサイト、カラシニコフ突撃ライフル、Sayano-Shushenskaya水力発電所のファンになります。 確かに、私たちが西洋の楽器を賞賛する理由を理解するのは難しいですが、私たちの楽器についてはわかりません。 だから、タランツール1.6。 トリックは何ですか？
このサイトでは、これはNode.JSとRedisの混合物のようなものであると書いています。 主なアイデアは、メモリ内の大量のデータをすばやく処理しながら、キー/値または大根が提供するデータ構造よりも重要なことを行うことです。 アイデアは、数十、数百ギガバイトのライブデータがあり、それらを使って本当に複雑なことをする機会があるということです。 Anticash、いくつかのトリッキーな相関関係を考慮し、オンラインゲームの状態を維持し、リアルタイムでプレイヤーの評価などを計算します。
あなたはこれをすべて見ることができ、unningなMemcashとして、私たちはすべてこれを行うことができますが、木の向こうの森を見ることさえできません。 たとえば、TarantulaとNode.JSの主な違いは、Tarantulaではイベント指向モデルではなく、グリーンストリームであることです。 古典的なシリアルコードを書くことができ、コールバックや先物にとらわれることなく、すべて効率的に機能します。 ソケット、ファイル、外部データベース（MySQL、PostgreSQL）へのノンブロッキングアクセスがあります。 大根との主な違いは、「データ構造」ではなく、MongoDBタイプのデータモデルがあることです。 たとえば、自動的に、一貫して、アトミックに更新されるセカンダリインデックスがあります。 それでも、それはすべてより少ないメモリを使用します。 しかし、私見、これは主要なことすらありません。 主なものは、トランザクションがあることです。 ストアドプロシージャの通常の開始、コミット、ロールバック。 また、大根とは異なり、ディスクストアがあります。 しかし、ディスクストアについては別に。
しかし、「主な」違いに加えて、主な違いは多くありません。 まず、すでに書いたように、MongoDBの場合と同様に、スキーマまたはインデックスをオンザフライで設定または変更できます。 テーブルまたはコレクションを表す言葉はスペースです。 作業ベースで新しいスペースを作成および変更でき、インデックスを追加および削除することもできます。 インデックスには反復機能があります。つまり、すべてのデータを昇順、降順で見ることができます。 一般に、Tarantulaのイテレータは、複雑なロジックを記述し、任意のデータ構造を実装するための主要なメカニズムです。つまり、Radishがすでに「行った」ものです。 もちろん、自由のためには、複雑さを払わなければなりません。 Tarantulaは、完全なRツリーインデックスを持つ唯一のインメモリデータベースです。 ポイントとポリゴンで検索する機能。
次に、ディスクストアがあります。 つまり、特定のスペースには、使用可能なRAMの量を何度も超えるデータを格納できます。 ディスクストアは、MySQLのようなプラグインストレージエンジンのアーキテクチャに実装されますが、MySQLとは異なり、すべてのエンジンはトランザクションをサポートし、共通のバイナリログを使用します。 なぜそれが重要であるかについて-例えば、ここにあるHabrのOleg Tsarev によるこの記事を読んでください。 ディスクストアには、Sofiaライブラリが使用されます。これもチームで作成されました。
第三に、異なる複製があります。 Tarantula 1.6は非同期マスターを使用しており、さらに詳しく説明する価値があります。 従来のレプリケーションマスタースレーブでは、1つのサーバーのみが変更のソースになります。 非同期マスターでは、レプリカのデータを更新できます。 つまり、読み取りと書き込みの両方にスケーラビリティがあります。 しかし！ 非常に大きなBUTが1つあります。これは覚えておく価値があります。 「非同期」という言葉は、それだけではありません。 変更が行われた時点で、サーバーは相互に変更を「調整」せず、マスターでのコミット後にネットワーク経由でレプリカに「到着」します。 したがって、2つのサーバー上の同じデータを一度に更新することで、簡単に「すべてを壊す」ことができます。 しかし、そのようなマスターマスターが必要な場合が多くあります。 たとえば、各レプリカの高可用性が必要であり、レプリカ間の距離が大きい場合。 たとえば、ロンドンとマイアミ、つまり 両方のノードで同じフィールドを同期的にフラッシュする機能の欠如。 1.7では、非同期レプリケーションに加えて、多くのノードでのデータの同期スケーリングと自動スケーリングを「準備」することに注意してください。 そして、このような「オプションパッケージ」では、Tarantulaは、OSS市場で100％のフォールトトレランスとトランザクションサポートを備えた唯一のRAMデータベースになります。 ただし、これは1.7であり、これに対応する必要があります。
まあ、それがすべてです。 現在、SberbankのいくつかのMail.Ruプロジェクトで1.6が実稼働しています。冬の間中、Avitoでの展開で見つかったバグが見つかりました。 タランチュラを使用している理由と、すべてのベータバグにもかかわらず他の何かを選択しなかった理由について、もっと詳しくお伝えしたいと思います。 また、プロジェクトでタランチュラを使用するかどうかは、自分で決めてください。 ボード上の投稿のみではなく、ドキュメント上。 まあ、またはこのレポートによるとここに。 まだ質問がある場合は、コメントで回答してみます。