it-swarm.asia

ما هي قاعدة بيانات مخزن المفتاح / القيمة؟

لقد كنت أبحث في صفحة ويكيبيديا عن NoSQL وهي تسرد العديد من الاختلافات في قاعدة بيانات متجر المفاتيح/القيمة ، ولكن لا يمكنني العثور على أي تفاصيل حول ما يعنيه متجر المفاتيح/القيمة في هذا السياق. هل يمكن لأحد أن يشرح أو يربط شرحًا لي؟ أيضا ، متى يمكنني استخدام قاعدة البيانات هذه؟

56
indyK1ng

هل أنت على دراية بمفهوم زوج المفتاح/القيمة؟ بافتراض أنك على دراية بـ Java أو C # هذا في اللغة كخريطة/تجزئة/بيانات/KeyValuePair (الأخير في حالة C #)

الطريقة التي يعمل بها موضحة في نموذج الرسم البياني الصغير هذا:

Color        Red
Age          18
Size         Large
Name         Smith
Title        The Brown Dog

عندما يكون لديك مفتاح (يسار) وقيمة (يمين) ... لاحظ أنه يمكن أن يكون سلسلة أو int أو ما شابه. تسمح لك معظم كائنات KVP بتخزين أي كائن على اليمين ، لأنه مجرد قيمة.

نظرًا لأنه سيكون لديك دائمًا مفتاح فريد لكائن معين تريد إرجاعه ، يمكنك فقط الاستعلام عن قاعدة البيانات الخاصة بهذا المفتاح الفريد واستعادة النتائج من أي عقدة تحتوي على الكائن (هذا هو السبب في أنها جيدة للأنظمة الموزعة ، نظرًا لوجود أشياء أخرى تتضمن الاستقصاء للعقد الأولى لإرجاع قيمة تطابق إرجاع العقد الأخرى).

الآن المثال الخاص بي أعلاه بسيط للغاية ، لذلك إليك نسخة أفضل قليلاً من KVP

user1923_color    Red
user1923_age      18
user3371_color    Blue
user4344_color    Brackish
user1923_height   6' 0"
user3371_age      34

لذا كما ترون فإن توليد المفتاح البسيط هو وضع "user" على رقم userunique والشرطة السفلية والكائن. مرة أخرى ، هذا اختلاف بسيط ، ولكن أعتقد أننا بدأنا نفهم أنه طالما يمكننا تحديد الجزء الموجود على اليسار وجعله منسقًا باستمرار ، يمكننا سحب القيمة.

لاحظ أنه لا يوجد قيود على القيمة الرئيسية (حسنًا ، يمكن أن تكون هناك بعض القيود ، مثل النص فقط) أو على خاصية القيمة (قد يكون هناك قيود على الحجم) ولكن حتى الآن لم يكن لدي أنظمة معقدة حقًا. دعونا نحاول أن نذهب أبعد من ذلك بقليل:

app_setting_width      450
user1923_color         Red
user1923_age           18
user3371_color         Blue
user4344_color         Brackish
user1923_height        6' 0"
user3371_age           34
error_msg_457          There is no file %1 here
error_message_1        There is no user with %1 name
1923_name              Jim
user1923_name          Jim Smith
user1923_lname         Smith
Application_Installed  true
log_errors             1
install_path           C:\Windows\System32\Restricted
ServerName             localhost
test                   test
test1                  test
test123                Brackish
devonly
wonderwoman
value                  key

ستحصل على الفكرة ... سيتم تخزين كل هذه في "جدول" واحد ضخم على العقد الموزعة (هناك رياضيات خلف كل شيء) وستطلب فقط من النظام الموزع القيمة التي تحتاجها بالاسم.

على الأقل ، هذا هو فهمي لكيفية عمل كل شيء. قد يكون لدي بعض الأشياء الخاطئة ، لكن هذه هي الأساسيات.


رابط ويكيبيديا الإلزامي http://en.wikipedia.org/wiki/Associative_array

42
jcolebrand

في مصطلحات SQL ، تعد قاعدة بيانات NoSQL عبارة عن جدول واحد يحتوي على عمودين: أحدهما هو المفتاح (الأساسي) والآخر هو القيمة. هذا كل ما في الأمر ، إنه سحر NoSQL.

يمكنك استخدام NoSQL لسبب رئيسي واحد: قابلية التوسع.

إذا كان تطبيقك يحتاج إلى معالجة ملايين الاستعلامات في الثانية ، فإن الطريقة الوحيدة لتحقيق ذلك هي إضافة المزيد من الخوادم. هذا رخيص للغاية وسهل مع NoSQL. في المقابل ، يعد توسيع قاعدة بيانات SQL التقليدية أكثر تعقيدًا.

فقط أكبر مواقع الويب الموجودة هناك تستفيد في الواقع من إمكانات NoSQL الكاملة ، أي Facebook ، حيث تعمل الآلاف من الخوادم Cassandra .

أوصي بشدة بقراءة منشور المدونة هذا ، بمقارنة SQL و NoSQL و ORM:

http://seldo.com/weblog/2010/07/12/in_defence_of_sql

25
vz0

أفترض أن لديك فهمًا أساسيًا لحركة NoSQL ونماذج قواعد البيانات غير العلائقية.

يعد Key Value store أحد نماذج قواعد البيانات غير المرتبطة ، مثل الرسم البياني ونماذج قواعد البيانات الموجهة نحو المستندات.

مخازن القيمة الرئيسية وحركة NoSQL

بشكل عام ، تمكنت SQL من التعامل مع البيانات المنظمة بشكل خاص وسمحت باستعلامات ديناميكية للغاية وفقًا لاحتياجات القسم المعني.

على الرغم من عدم وجود منافسين حقيقيين لـ SQL في هذا المجال المحدد ، إلا أن حالة الاستخدام في تطبيقات الويب اليومية مختلفة. لن تجد مجموعة ديناميكية للغاية من الاستعلامات المليئة بالصلات الخارجية والداخلية ، والاتحادات والحسابات المعقدة عبر الجداول الكبيرة. ستجد عادة طريقة تفكير ذات أهداف محددة. خاصة مع اعتماد أنماط مثل MVC ، عادة ما لا يتم تصميم البيانات في النهاية الخلفية لقاعدة بيانات ، ولكن من أجل التكامل المنطقي الذي يساعد الأشخاص أيضًا على القدرة على التعامل مع فهم البنى التحتية للبرامج الضخمة. ما يتم فعله لوضع هذه النماذج الموجهة للكائنات في قواعد البيانات العلائقية هو قدر كبير من التطبيع الذي يؤدي إلى تسلسل هرمي معقد للجداول ويوجه تمامًا ضد الفكرة الرئيسية وراء البرمجة الشيئية. يجب على الخوادم التي تلتزم بمعيار SQL أيضًا تنفيذ جزء كبير من التعليمات البرمجية التي لا فائدة منها لتخزين البيانات البسيط من أي وقت مضى وتضخم بصمة الذاكرة ومخاطر الأمان ولها نتائج أداء نتيجة لذلك.

حقيقة أن SQL تسمح بالاستعلامات الديناميكية العشوائية لمجموعات معقدة من البيانات يتم جعلها عديمة الفائدة باستخدام قاعدة بيانات SQL فقط للتخزين المستمر للبيانات الموجهة للكائنات ، وهو ما تفعله معظم التطبيقات هذه الأيام.

هنا يأتي دور متاجر Key Value. Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship. عادة ما تكون البيانات نفسها نوعًا من بدائية لغة البرمجة (سلسلة ، عدد صحيح ، صفيف) أو كائن يتم تنظيمه بواسطة ارتباطات لغات البرمجة بمخزن القيمة الرئيسية. هذا يحل محل الحاجة إلى نموذج بيانات ثابت ويجعل متطلبات البيانات المنسقة بشكل صحيح أقل صرامة.

They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval. يتمثل الاختلاف الأكبر في المتاجر "الأبسط" في الطريقة التي (أو لا يمكنك) من خلالها المصادقة على المتاجر المختلفة أو الوصول إليها (إن أمكن). في حين أن مزايا السرعة في تخزين البيانات واسترجاعها قد تكون سببًا للنظر فيها عبر قواعد بيانات SQL الشائعة ، فإن هناك ميزة كبيرة أخرى تظهر عند استخدام مخازن القيمة الرئيسية هي أن الشفرة الناتجة تميل إلى أن تبدو نظيفة وبسيطة عند مقارنتها بسلاسل SQL المضمنة في لغة البرمجة الخاصة بك. هذا شيء يميل الناس إلى محاربته باستخدام أطر عمل رسم الخرائط المرتبطة بالعلاقة مثل الإسبات أو السجل النشط. يبدو أن امتلاك مصممي خرائط ارتباطية للكائنات هو في الأساس محاكاة لمخزن قيمة رئيسي من خلال إضافة الكثير من التعليمات البرمجية المعقدة حقًا بين قاعدة بيانات SQL ولغة برمجة موجهة للكائنات.

يجتمع مجتمع كامل من الناس تحت علامة " NoSQL " ويناقشون هذه المزايا وأيضًا عيوب استخدام بدائل لأنظمة إدارة قواعد البيانات. اقرأ المزيد
هذه مقالة قديمة بعض الشيء ، لكني وجدت أنها مفيدة جدًا.

when would I use such a database?Could someone explain or link an explanation to me?
إنه أكثر قرارًا معماريًا ، وقرار قابل للنقاش ... عليك أن تفكر في الكثير من العوامل مثل قابلية التوسع والأداء وما إلى ذلك ...

انظر أدناه الشرائح/المقالات وستحصل على فكرة ومتى ولماذا ولماذا لا تستخدم متجر القيمة الرئيسية :)

14
CoderHawk

شرح آخرون هذا ، لكنني سأطعن على أي حال.

تقوم قاعدة بيانات المفتاح/القيمة بتخزين البيانات بواسطة مفتاح أساسي. يتيح لنا هذا تحديد سجل في دلو بشكل فريد. نظرًا لأن جميع القيم فريدة ، فإن عمليات البحث سريعة بشكل لا يصدق: فهي دائمًا ما تبحث عن قرص بسيط.

القيمة هي فقط أي نوع من القيمة. الطريقة التي يتم بها تخزين البيانات غير شفافة لقاعدة البيانات نفسها. عند تخزين البيانات في مخزن مفتاح/قيمة ، لا تعرف قاعدة البيانات أو تهتم إذا كانت بتنسيق XML أو JSON أو نص أو صورة. في الواقع ، ما نقوم به في متجر المفتاح/القيمة هو نقل المسؤولية لفهم كيفية تخزين البيانات خارج قاعدة البيانات إلى التطبيقات التي تسترد بياناتنا. نظرًا لأن لديك فقط مجموعة واحدة من المفاتيح للقلق بشأن كل مجموعة ، فمن السهل جدًا نشر المفاتيح عبر العديد من الخوادم واستخدام تقنيات البرمجة الموزعة لتمكين الوصول إلى هذه البيانات بسرعة (يخزن كل خادم نطاقًا من البيانات) .

عيب هذا النهج للبيانات هو أن البحث مهمة صعبة للغاية. تحتاج إما إلى قراءة كل سجل في بياناتك أو تحتاج إلى إنشاء فهارس ثانوية بنفسك.

هناك بعض الأسباب التي قد تجعلك ترغب في استخدام قاعدة بيانات مفتاح/قيمة:

  • عندما يكون أداء الكتابة هو أعلى أولوياتك. Mozilla Test Pilot يستخدم قاعدة بيانات مفتاح/قيمة لتسجيل البيانات بسرعة.
  • عندما تكون القراءات مضمونة أن تحدث فقط بواسطة PK.
  • عندما تعمل مع نموذج بيانات ثابت.
  • عندما تعمل مع نموذج بيانات غني ومعقد لا يمكن تصميمه في نظام إدارة قواعد البيانات الديناميكية.

هناك العديد من الأسباب لاستخدام قاعدة بيانات المفتاح/القيمة كما هو الحال مع استخدام نظام إدارة قواعد البيانات (RDBMS) وهناك العديد من الحجج لتبرير واحد على الآخر. من المهم إلقاء نظرة على كيفية الاستعلام عن بياناتك وفهم كيف يوجه نمط الوصول إلى البيانات كيف ستقوم بإدراج البيانات وتخزينها.

فقط تذكر أن قاعدة البيانات الرئيسية/القيمة هي نوع واحد فقط من قاعدة بيانات NoSQL.

12
Jeremiah Peschka

إذا كانت لديك قاعدة بيانات علائقية ، فيمكنك بسهولة تجربة ذلك:

create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);

هذه هي الطريقة التي كانت بها جميع قواعد البيانات ، مع كون Berkeley DBM مثالًا جيدًا ، منذ عام 1979. ومنذ ذلك الحين ، تقدمت الأشياء (يمكن أن يكون لديك العديد القيم لكل مفتاح في أي RDBMS). بالنسبة للعديد من التطبيقات ، يكون مخزن القيمة الرئيسية كافيًا (على سبيل المثال ، كيف يخزن Sendmail الأسماء المستعارة له). ولكن إذا وجدت نفسك تعالج القيمة مسبقًا في التعليمات البرمجية الخاصة بك (أو سلاسل متسلسلة لإنشاء "المفتاح" الخاص بك) ، فربما تقوم بتقسيم القيمة على محدد أو تحليله ، قبل أن تتمكن من استخدامه ، فمن المحتمل أن تكون أفضل حالًا مع RDBMS وتخزينها في الواقع بهذه الطريقة.

8
Gaius