問題タブ [schemaless]

独自のフィールド (ID、名前) を持つ製品で e コマースを作成しています: これは、C# にあるオブジェクトです。

これは、C# で neo4j に製品を生成するための私のコードです。

ユーザーまたは私が価格などの他の属性を製品ノードに追加する必要があると仮定すると、最初に新しい製品属性をクラスに追加します

次に、暗号コードを変更して、net 属性/プロパティを持つ製品を追加します。

明らかに、これはハードコーディングされたアプローチであり、動的なデータベース/サイトには適していません。

私は RDBMS に慣れていたので、この種の問題は EAV と多数のピボットでしか解決できなかったので、Nosql (つまり Neo4J) が EAV なしで変数属性フィールドを処理するのに役立つことを期待していました。コードを生成するコードは解決策になるでしょうか?

• 私の頭に浮かぶのは、動的コード/変数またはcodeDomを使用することです.これは行く方法ですか? 他のエレガントなソリューションはありますか？
• 説明や勉強するトピックを教えてください。
• NoSql はスキーマレスであるべきですが、スキーマレス アプリケーションはそれほど簡単ではありません。

Solr + Cell (Tika) + スキーマレス モードを使用していますが、インデックスを作成するためにファイルを送信すると、提供したリテラルが結果ドキュメントに保存されていません。*:*これは、solr 管理 UI でクエリを実行したときに返されるものです。ID フィールドとversionのみが含まれていますが、ファイル内の他のリテラルやコンテンツは含まれていません。

これが私が送っているPOSTです：

SolrJ を使用して、次のコードでこのリクエストを送信しています。

ドキュメントを作成しますが、指定したリテラル値を保存できません。また、ファイルのコンテンツから読み取ったメタデータやコンテンツも保存されていないと確信しています。

このコードを使用すると、すべてが正常に保存されることを確認できます。

では、なぜこれらは保存されていないのでしょうか。

当社の REST API を使用すると、ユーザーはスキーマレスのカスタム JSON を一部の REST リソースに追加できます。Elasticsearch で検索できるようにする必要があります。このカスタム データとその構造は、同じ種類のリソース間で完全に異なる場合があります。

次のサンプル ドキュメントを検討してください。

customDataスキーマに準拠する以外のすべてのフィールド。customDataは常に JSON オブジェクトですが、そのオブジェクト内のすべてのフィールドと値は、リソースによって大幅に異なる可能性があります。customData 内の特定のフィールド名または値 (または値の型でさえも) が、任意の 2 つのリソース間で同じであるという保証はありません。ユーザーはこれらのフィールドを自由に編集できます。

この検索をサポートする最善の方法は何ですか?

解決策は、インデックスが作成されたときにマッピングを作成しないことであると考えましたcustomDataが、その後、クエリができなくなります (これは、ES ドキュメントの内容に反しています)。これは、マップされていないプロパティに対するクエリが機能する場合に理想的なソリューションであり、このアプローチでパフォーマンスの問題が発生することはありませんでした。ただし、その問題について複数のテストを実行した後、それを機能させることができませんでした.

これは何か特別な設定が必要ですか？それともドキュメントが間違っていますか？なぜそれが機能しないのかについての説明をいただければ幸いです。

これは現在うまく機能していないため、いくつかの代替ソリューションを考えました。

1. インデックスの再作成: ユーザーが値の型が異なるプロパティを更新するたびに、そのドキュメントを含むすべてのインデックスを再作成する必要があるため、コストがかかります。パフォーマンスが非常に悪いため、これは実際のオプションではない可能性があります。

2. 複数一致クエリを使用します。customData オブジェクトに変更があるたびに、customData フィールド名にランダムな文字列を追加することでこれを行います。たとえば、インデックスが作成されるドキュメントは次のようになります。

   これは、ES が「ランダム」フィールドごとに新しいマッピングを作成することを意味し、クエリを実行するときに、フィールド名に「で始まる」ワイルドカードを使用して、フレーズの複数一致クエリを使用します。例えば：

   これは実行可能な解決策になる可能性がありますが、このようなマッピングが多すぎるとパフォーマンスに影響する可能性があることを懸念しています. インデックスのマッピングが多すぎると、パフォーマンスに影響はありますか? 定期的にインデックスを再作成することで、マッピングが多すぎることを軽減できるのでしょうか?

   これもハックのように感じられ、ES がネイティブに処理する必要があります。何か不足していますか？

これについての提案は大歓迎です。

ありがとう！

私が知っているスキーマレスのプロジェクトにCouchbase Liteデータベースを使用しています。これで問題が解決するので非常に満足していますが、NoSQL（ドキュメントデータベース）の主キー制約に関連する1つの疑問が生じます。

すべてのスキーマ データベースがテーブルで表されることは周知のとおりであり、これらのテーブルにはプライマリ/フォージン キーがある場合とない場合があります。たとえば、usn(大学の座席番号) という主キーを持つ Student というテーブルがあり、その他の属性 (名、姓、住所、連絡先番号など) があるとします。

私たち | ファーストネーム | 姓 | 住所 | 連絡先番号

2BA11CS409 | abc | mnq | バンガロール | 1234567890

2BA11CS410 | xyz | PQR | ムンバイ | ムンバイ 1234567809

ここで、2BS11CS409 値をもう一度追加しようとすると、主キー制約違反 (重複キーを追加できない) というエラーが表示されます。

しかし、文書データベースの場合、文書内の一意の値をどのように識別し、

各ドキュメントには一意の ID が 1 つあり、そのキーはデータベースで検索するためにインデックス化されていることはわかっていますが、上記と同じ値を持つ別のドキュメントを作成すると、

usn を使用して 1 つのデータベースにアクセスしようとすると、1 つのドキュメントだけが返されますが、2 つのドキュメントが返されますが、それらは同一または異なる可能性があります。

リレーショナル データベースに存在するドキュメント データベースの主キー/一意キーの種類の概念を知る必要があります。または、いくつかの記事にリダイレクトできます

ありがとうございました。

リレーショナル データベース、ドキュメント ストア、グラフ データベース、および列指向データベースについて調べた結果、Cassandra のようなものが自分のニーズに最も適していると結論付けました。特に、その場で列を追加できることと、厳密なスキーマを必要としないことは、私にとって大きなメリットです。これは、かなり斬新なグラフ db と実績のある rdbms の間のギャップをうまく埋めているようです。

しかし、単一ノードで Cassandra を実行する方法が気になります。他の多くの人と同じように、私は少量のデータからしか開始できないため、複数のノードから開始することは実際的ではありません。もう 1 つの優れた SO の質問に基づいて:通常 MySQL で行うように、「単一の小さな」Cassandra サーバーから始めてみませんか? Cassandra は、マルチノード セットアップから得られる可用性などの利点を放棄しても構わないと思っている限り、単一ノードとして実際に問題なく実行できると結論付けました。

SO: How to design a database for User Defined Fields? で説明されているように、たとえば RDBMS にフィールドを動的に追加する方法もあるようです。これは、ある程度、スキーマレス性を模倣します。

そこで、Cassandra と MySQL がどのように比較されるかを理解したいと思います - 機能とパフォーマンスに関して、単一ノードのセットアップで? 私の状況で誰かに何をアドバイスしますか-後でCassandraに切り替える計画/意図を持つ単純なRDBMSから始めますか? それとも Cassandra から始めますか?

動的フィールド名にハッシュ文字を含めることができるようにしたいと考えています。Solrがスキーマレスモードの場合、これは可能ですか?

指定された JSON を HBase (JSON または Thrift) 挿入に変換するソフトウェアはありますか?

次のJSONを自分のストリームに受け取ったとしましょう

この情報を に追加するには、Hbaseに送信HTTP PUTする必要があります。http://192.168.44.187:8000/<TABLE>/<ROW_ID>/<COL_FAMILY>:<COLUMN>変更する必要があるかどうか <ROW_ID> = www.somesite.comなどです。したがって、http://192.168.44.187:8000/t1/www.somesite.com/ColFam:label追加しlabelます。さらに、 の本体にPUTは、対応するbase64フォーマットされた値が含まれている必要があります。