NewSQL: SQL لن تذهب إلى أي مكان

يبلغ عمر NoSQL قرابة 10 سنوات ، ويمكنك استخلاص أية استنتاجات وتعميمات بأمان. سنفعل ذلك ونتحدث عن تطوير NoSQL.

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

و Konstantin Osipov ( kostja ) ، المطور والمهندس في Tarantool DBMS ، الذي تحدث عن اتجاهات NewSQL في تقريره في RIT ++ 2017 ، سيساعدنا في ذلك ، لأنه من المفترض أن يفهم المهندس المعماري ما يحدث في عالم قاعدة البيانات بحيث على الأقل إعادة اختراع العجلة.


حول المتحدث : يعمل كونستانتين أوسيبوف الآن على تارانتول ، ولكنه شارك سابقًا في تطوير MySQL ، وعندما بدأ كونستانتين العمل على قاعدة بيانات جديدة ، كان مرتبكًا للغاية لماذا يجب القيام بذلك على الإطلاق ، ولماذا كانت هناك حاجة إلى قاعدة البيانات التالية. على وجه الخصوص ، كان الموقف تجاه NoSQL متشككًا للغاية ، فيما يتعلق بـ "under-SQL".

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

الخطة

• الخلفية . تذكر كيف ولدت NoSQL ، ما هو جيد وما هو سيئ فيه.
  
• دعونا نرى ما الذي صمد أمام NoSQL اختبار الزمن .
  
• NoSQL SQL : N1QL و CQL. دعونا نحلل الميزات الموجودة بالفعل في SQL ، والتي تظهر الآن في NoSQL DBMS.
  
• NoSQL ميت بالفعل ، ولم يولد NewSQL بعد: مدى اختلاف الأنبوب عن SQL في SQL في NoSQL.
  
• القيم الفريدة لـ NoSQL . سنرى ما حدث في 10 سنوات من الجهد وما سيحدث بعد ذلك.
  
• قواعد بيانات متعددة النماذج و NewSQL . دعونا ننظر إلى الأمام قليلاً في ما سيكون في السوق غدا.
  

مبادئ NoSQL

يحاول العديد من الناس التمسك بمصطلح NoSQL الآن ، ولكن تم اعتماده على نطاق واسع في عام 2009 عندما ظهرت علامة #nosql . اخترع المطور من Last.FM هذه العلامة لقواعد البيانات الموزعة.

بعد ذلك ، بدأت العلامة تكتسب شعبية على Twitter ، وأصبحت NoSQL خزان تصريف أو قمع للإحباط ، كما أسميها - الإحباط الذي تراكم على مدى سنوات عديدة من العمل مع قواعد البيانات التقليدية.

NoSQL هو وسيلة للإحباط ، وهي علامة استوعبها لنفسه كل شخص لم يكن لديه ميزات SQL كافية.

يجب أن يكون هذا الإحباط منظمًا إلى حد ما ويحدد أن الناس لا يحبون في أغلب الأحيان في DBMSs التقليدية. هناك 3 مجموعات كبيرة من المهام التي تم إنشاؤها NoSQL لحلها:

• التحجيم الأفقي
  
• نماذج بيانات جديدة ؛
  
• نماذج جديدة من الاتساق.
  

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

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

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

إن دمج نموذج البيانات ونموذج المقياس هو بالضبط المشكلة التي تم حلها باستخدام النموذج العلائقي. مرحبًا بك في السبعينيات.

بالإضافة إلى نماذج البيانات الجديدة ، نفذت NoSQL نماذج اتساق جديدة. نعم ، نعم ، مرة أخرى هذه نظرية- CAP الشهيرة. الحديث عن نظرية CAP يسعدني طوال الوقت - من يحتاجها على الإطلاق؟ نظرًا لعدم وجود سمك طازج من الانتعاش الثاني ، لذلك لا توجد إجابات أخرى على السؤال حول اتساق البيانات باستثناء واحدة: يجب أن تضمن قاعدة البيانات هذا الاتساق . لذلك ، فإن النماذج الجديدة للاتساق هي أيضًا ، في رأيي ، اتجاه الموت.

NoSQL اليوم

الأطروحة التي أريد أن أوضحها أولاً هي أن حركة NoSQL بأكملها باقية:

• التحجيم الأفقي
• نماذج نماذج البيانات الجديدة ونماذج بيانات الرسم البياني ؛
• نماذج جديدة من الاتساق.

من الأطروحات حول نماذج البيانات الجديدة ، نجا حوالي واحد ونصف وتوفي أطروحة حول نماذج الاتساق تمامًا.

غطاء الموت

لماذا لم تنجو بعض نماذج الاتساق؟

● الاتساق النهائي: مصطلح التضخم
من يستخدم قاعدة بيانات تحتوي على ساعة متجه عاملة ومنطق العمل الخاص بالتطبيق موجه نحو ذلك؟ - لا أحد. من يستخدم قواعد البيانات التي تحتوي على CRDT (أنواع البيانات المنسوخة الخالية من التعارضات)؟ من يستخدم رياك؟ - لا أحد. ماذا يستخدم الناس؟ في كثير من الأحيان PostgreSQL ، في كثير من الأحيان قواعد أخرى ، على سبيل المثال ، MongoDB.

● MongoDB: يتم استبدال الذرية بمعزل ، وتضاف المعاملات في 3.xx
تحتوي قاعدة البيانات هذه على نسخ غير متزامن. هذا أمر سهل الفهم ، على الرغم من وجود 4 أنواع من النسخ المتزامن غير المتزامن . يمكن أن يحدث تكرار بيانات المعاملات بعد الالتزام بالمعاملة محليًا ؛ قبل تنفيذ المعاملة محليًا.

بمعنى ، يمكن ربط نقطة الالتزام بقاعدة البيانات الرئيسية بنقطة الالتزام بالنسخة المتماثلة بطرق مختلفة أيضًا.

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

في البداية ، كان لدى MongoDB وضع: وصل الطلب على الخادم ، وردت قاعدة البيانات على ما يرام - لم تصل حتى إلى القرص حتى الآن ، أو إلى المجلة - لم تذهب إلى أي مكان. ونتيجة لذلك ، يعمل كل شيء بسرعة كبيرة ، ولكن بعد ذلك بدأوا في انتقاد MongoDB لهذا ، وبشكل افتراضي في الإصدارات الأحدث 3+ ، بعد كل شيء ، بدأ أولاً في كتابة المعاملة إلى السجل ، وبعد ذلك فقط أرسل تأكيدًا إلى العميل.

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

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

دعونا نلقي نظرة على تاريخ المعاملات في NoSQL. في البداية ، قام MongoDB بتنفيذ atomicity على مستوى المستند. ثم تمت إضافة وضع تنفيذ معزول للسماح للمطورين ، إذا كانوا يريدون ذلك حقًا ، بتحديث العديد من المستندات تلقائيًا.

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

ولكن اتضح أن هذا لا يعمل. يجب تطبيع البيانات لتجنب تكرار التخزين. يجب تطبيعهم للاستفسارات التحليلية. في النهاية ، نموذج البيانات آخذ في التطور - والوثيقة التي تمكنت أمس من حفظ جميع المعلومات اللازمة لسيناريو الأعمال اليوم تحتاج إلى توسيعها واستكمالها.

هل تظهر مشاكل الذرية؟ مدى ارتباط نماذج البيانات ارتباطًا وثيقًا بنماذج الاتساق - ظهور المعاملات والنسخ المتزامن يجعل معظم النماذج في NoSQL غير ضرورية.

نماذج البيانات

الآن دعونا نتحدث عن القصة التالية - القصة مع نماذج البيانات.

مجموعات نماذج البيانات اخترع بعد SQL:

• القيمة الرئيسية
  
• وثائقي
  
• متجر عريض
  
• خادم هيكل البيانات (لـ Redis) ؛
  
• قواعد بيانات الرسم البياني.
  

رائع! لدينا الكثير من نماذج البيانات! وما مدى ارتفاعها؟

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

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

أي أن القياس الأفقي هو اتجاه يضع ضغطًا على الجميع ، بما في ذلك مخترعي نماذج البيانات الجديدة. إذن ما هي نماذج البيانات الجيدة للتدرج الأفقي ، وأيها سيئ؟

هل هو جيد أم سيئ للتحجيم الأفقي؟ الجواب ، في الواقع ، مثير للجدل تمامًا ، وسنعود إليه لاحقًا.

ريديس

عندما أضافت Redis مجموعة Redis ، اتضح أنه لا يتم قياس جميع عمليات نموذج البيانات بشكل أفقي بشكل طبيعي.



هذا اقتباس من الوثائق حيث يكتبون أن شيئًا ما يناسبهم على جزء معين ، وشيء يعمل حقًا كما هو الحال في مجموعة حقيقية.

المشكلة الأساسية لهذا النهج هي نفسها كما في MySQL ، التي التقطناها وصافحناها. أي أن المطور لديه نموذجان للبيانات:

1. في واحدة ، يفكر في إطار الجبر العلائقي.
   
2. وبعد ذلك ، عندما يفكر في عملية تقسيم مستقلة ، يفكر في نموذج بيانات الجبر القائم على العلاقات.
   

يجب أن يكون نموذج البيانات الجيد عالميًا . ما هو جميل في الجبر الارتباطي - نتيجة الإسقاط هي علاقة ، ونتيجة أي عامل هي علاقة. وبمجرد أن نبدأ مشاركة MySQL في الكتلة يدويًا ، نفقد ذلك.

ومع ذلك ، يضيف Redis مجموعة Redis لأن كل شخص يريد القياس أفقيًا .

قواعد بيانات الرسم البياني

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

دعونا نلقي نظرة على مشكلة تحجيم DBMSs الرسم البياني - تواجه SQL DBMSs حواجز تحجيم مشابهة جدًا.



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

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



إذا عملت بعض الاستعلامات على الأقل في المخطط السابق بشكل جيد ، فإن 100٪ من الاستعلامات غبية هنا ، لأن معظم استعلامات قاعدة البيانات مرتبطة بانتقال الرسم البياني. يجب أن يذهب أي منعطف من العقدة إلى مكان ما ، وفي أغلب الأحيان ، من أجل حساب الطلب ، تحتاج إلى الانتقال إلى عقدة أخرى.



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

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

لذلك ، يتم الآن قياس Neo4j بشكل عام مثل قواعد بيانات SQL الكلاسيكية. لقد عملوا على التقسيم لبعض الوقت ، في محاولة لحل المشاكل الموضحة.

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

لذا ، على سبيل المثال ، إذا أخذنا في الاعتبار قواعد بيانات Key-Value و Document بشكل محض ، فإن بياني هو أنها لن تكون كذلك. إذا نظرت إلى قواعد بيانات الرسم البياني ، فإنها تشغل بالفعل جزءًا مهمًا ، ولكنها تحت ضغط التحجيم الأفقي.

هل ستختفي قواعد بيانات الرسم البياني؟ من المرجح أن الأعمدة ، مثل المستندات ، سيتم تضمينها في جميع المنتجات . يُسمى هذا الاتجاه قواعد بيانات متعددة النماذج ، وسأعطي لاحقًا في التقرير مثالًا على كيفية عمل ذلك عمليًا. ولكن في الوقت الحالي ، كتوضيح آخر لاتجاه قواعد البيانات متعددة النماذج ، دعنا ننظر إلى JSON.

جسون

فيما يلي مثال لكيفية عمل الاتجاه الذي أصبح شاملاً للجميع.

أصر على أن أي قاعدة بيانات قادرة على دعم JSON بأي شكل من الأشكال ستدعم JSON.

ربما لن تدعم بعض قواعد البيانات لحوسبة المصفوفة JSON. ولكن على الأرجح هناك سيكون مفيدًا. وكل الباقي سيكون بالتأكيد.

	MySQL	PostgreSQL	ريديس	كاوتش	كاساندرا	Neo4j
تخزين JSON	نعم	نعم	نعم	نعم	نعم	نعم فعلا!
عمليات حقل JSON	نعم	نعم	نعم	نعم	لا	لا
الاستعلام Json	نعم	نعم	لا	نعم	نعم	لا
فهرس JSON الثانوي	نعم	نعم	لا	نعم	لا	لا

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

وبالتالي ، فإن قواعد البيانات متعددة النماذج ، ولا سيما JSON كنوع بيانات موجود في جميع المنتجات تقريبًا ، هو ما سيبقى من NoSQL على محمل الجد ولفترة طويلة.

ولكن إذا كانت جميع قواعد البيانات تدعم JSON ، فلماذا تحتاج إلى قواعد بيانات NoSQL على الإطلاق؟

بقيت قصة واحدة فقط - التحجيم الأفقي. نريد التوسع أفقيًا ، ولهذا السبب نستخدم شيئًا غير MySQL أو PostgreSQL.



هذه هي الكلمة الرئيسية لتوماس أولين ، نائب رئيس MySQL Engineering في Oracle ، والذي يتحدث عن مستقبل MySQL. يحدث نفس الشيء في مجتمع Postgres والمنتجات العلائقية الأخرى. يؤثر ضغط التحجيم الأفقي على 100٪ من المنتجات بسبب الانتقال إلى التقارب المفرط والحوسبة السحابية.

يقول توماس أن رؤيتهم هي منتج واحد مع توفر عالٍ وقابلية للتوسع خارج الصندوق. نحن نتحدث عن توافر عال في المقام الأول InnoDB Cluster ، وهذا هو تكرار المجموعة + InnoDB. لا تموت قاعدة البيانات هذه أبدًا ، حتى لو تم ضربها بمطرقة.

ثم يكتب توماس " ميزات التحجيم المخبوزة " - "لقد قمنا بخبز كل هذه الميزات." النقطة هي أنه من خلال الإصدارات x (أعتقد أن x = 2 ، 3) سيحصلون على مجموعة MySQL في شكلها النقي ، والتي ستدعم SQL على الكتلة ، وتخزين JSON في المجموعة.

يوجد بالفعل لدى MySQL بروتوكول X مشابه جدًا لـ MongoDB وهو مصمم للعمل مع JSON.

SQL في NoSQL

الآن دعونا ننظر إلى الحركة من الجانب الآخر. من أجل ذكر الموت ، تحتاج إلى النظر ليس فقط في كيفية اعتماد SQL لمبادئ NoSQL ، ولكن أيضًا بالعكس.

	مونغودب	كاوتش	كاساندرا	ريديس
مخطط البيانات	نعم *	لا	نعم	لا
القيم الفارغة / القيم الغائبة	نعم *	نعم	نعم	لا
ينضم	نعم	نعم	لا	لا
مفاتيح ثانوية	نعم *	نعم	نعم ولكن ...	لا
تجميع حسب	نعم *	نعم	لا	لا
JDBC / ODBC	لا	نعم	لا	لا

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

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

كاوتش

في رأيي ، لدى Couchbase أكبر مجموعة من الاحتمالات من عالم SQL. يعلم الجميع أن Couchbase Memcached . كان لدى Dormando ( Alan Kasindorf ) ، أحد مطوري Memcached رؤية منتج مختلفة تمامًا ، والتي لم تتضمن التحجيم الأفقي. لذلك ، متشعب Memcache من أجل التوسع أفقيًا. سارت على ما يرام وبدأت في ممارسة الأعمال حولها ، ثم اندمجت مع CouchDB وما إلى ذلك.

تقول Couchbase لنفسها في البداية أنها قاعدة بيانات مخططة . Memcache هي في الأساس قيمة مفتاح بسيطة للغاية. الآن دعونا نرى كيف يتغير هذا التعريف الذاتي بمرور الوقت.

على سبيل المثال ، يحتوي Couchbase على مفاتيح ثانوية ، والمفاتيح الثانوية هي في الواقع بداية النظام . إذا قلت أن لديك بعض الحقول التي تقوم من خلالها بإنشاء الفهرس ، فأنت تتحدث بالفعل عن مخطط مستندات البيانات التي تقوم بتخزينها.

علاوة على ذلك ، نظرًا لأن Couchbase يقطع تدريجيًا القصة الكاملة حول Memcache الماضية من التوثيق اليوم ، فإنهم سيقطعون أيضًا القصة حول الاتساق النهائي غدًا ، على الرغم من أنه لا يزال هناك اليوم الكثير من القصص حول نقص اتساق القراءة - المفاتيح الثانوية ثابتة في نهاية المطاف.

لكن الصيد هو أن Couchbase لديه JDBC / ODBC. , Tableau ClickView — , CQL SQL. — SQL.

, .



, - , , , - — , SQL.

, IS MISSING — , IS NULL?

JDBC, ODBC SQL ? 30-40 , SQL- SQL , , : look-in, , ..

, . , , .

, Couchbase JDBC/ODBC — . , — .

Secondary keys

, NoSQL — , — , . OrientDB, , , .

SQL- , ( , ), NoSQL, .

NoSQL- secondary keys. secondary keys?

( — ):

1. , , . , range-, SQL . range- map/reduce .
   
2. . index notes, . range- .., .
   

, , , , , . , .

. , NoSQL- SQL, , , .

: CockroachDB? : , . , MySQL — legacy. , , ..

, NoSQL- legacy 10 . , , . SQL- , PostgreSQL, , MySQL Couchbase , True NewSQL.

, secondary keys. MongoDB SQL, . , JOINs, , .

Redis No, . Redis , — . , , , .

, Redis — , - . , Redis-, SQL. , Redis SQLite, — storage — Redis', in memory.

NoSQL , , ?

, NoSQL . , , , SQL . SQL .

schemaless , , , waterfall : agile, - . , , CREATE TABLE, .

, online alter table. Oracle , .

SQL , . MongoDB — , .

MongoDB , schemaless. . , , strict. validation level validation action. Validation level , .

, , - . , , . validation action reject, warn: warning, validation action.

. , MongoDB ( Tarantool), .
Cassandra JSON, . — , . , , NoSQL, .

-, NoSQL SQL .



eventually consistent , , , . , — . .

?

, , . BigQuery , , Vertica, .

NoSQL . , SELECT LTP, LTP - Key-value.

, NoSQL- .

SELECT JOIN , , , — ..

NoSQL:

, , , . domain-specific languages .

NoSQL DSL. — RethinkDB ReQL . , — domen specific language. Python, JavaScript .. — . SQL , .

ReQL, . ReQL , , — . RethinkDB, , , , , .

:

• Elasticsearch Query Language:
  • MIN/MAX/AVG;
  • derivative/percentiles/histogram/cumulative sum/serial diff;
• JSONIQ;
  
• GraphQL;
  
• SparQL;
  
• Pregel.
  

, , SQL, . - SQL!

SQL — OLTP , GROUP BY, Window Functions, (recursive). SQL , . ! , , .

, , . , , , , .

, , Pregel — . : , / . - , . , , .

- SQL, , , .

, , , , . .

-

, , . .



ArangoDB, - : , , ( ), , .



, , . . : , .



, , . , , , , . .

. , , relations. , relation , , relations ..

UPSERT:

لا يتعلق هذا تمامًا بـ NoSQL ، ولكن هذا اتجاه يبدو مهمًا جدًا بالنسبة لي - هذا هو التخزين الأمثل للكتابة - والذي ، في رأيي ، سيبقى معنا بجدية ولفترة طويلة.

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

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

في رأيي ، لا توفر قاعدة بيانات واحدة هذا الآن ، ولكن جاذبية الخوارزميات المحسنة للكتابة رائعة جدًا لدرجة أنني أريد حقًا هذا الاحتمال. لأنه بفضل الكتابة المحسنة للتخزين ، فإن أشجار LSM (RocksDB و LevelDB وغيرها) أداء الكتابة دون قراءة أعلى بمقدار مرتين من أداء الكتابة مع القراءة . بدلاً من 10 آلاف طلب في الثانية ، قد يكون هناك مليون على عقدة واحدة.
هذا هو السبب في فوز قاعدة بيانات Time Series الآن لأنها تفتقر إلى هذه الفجوة الدلالية. يتم تعريف دفق البيانات الواردة فيها بوضوح على أنها سلسلة زمنية ويتم كتابتها بسرعة كبيرة وصغيرة الحجم في قاعدة البيانات ، على وجه الخصوص. لأنك لست بحاجة إلى التحقق من التفرد. هذا ترتيب من حيث الحجم بشكل أسرع لأنه ببساطة في قواعد البيانات التقليدية لا توجد مثل هذه العملية الدلالية التي ستكتب فقط.

أعتقد أنه سيظهر.



أين يذهب كل هذا بعد ذلك؟ إذا نظرت بعيدًا جدًا ، فلن يتوقف الابتكار عند NoSQL و NewSQL. إن فهمنا للمعلومات يتطور باستمرار.

في رأيي ، أن أحد أهم اتجاهات المستقبل هو أننا سنحذف المعلومات أقل وأقل.

لهذا ، ولدت سلسلة كاملة من المنتجات ، والتي تسمى قواعد البيانات الزمنية.

بعد NewSQL: قاعدة بيانات مؤقتة

فيما يلي لقطات شاشة من Microsoft SQL Server. هذه قاعدة بيانات تسمح لك بطرح الأسئلة إلى نقطة زمنية: هناك SELECT للحالة الحالية ، ولكن لا يزال من الممكن إجراء SELECT لبعض التاريخ في الماضي.



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



من وجهة نظر الهيكل الداخلي ، هذا هو في الواقع الجدول الرئيسي والجدول مع التاريخ. يرتبط كل خط بمرتين معروفتين للنظام. هذه ليست عمودين فقط قمت بإضافتها ، ولكن البيانات التي يدعمها النظام تلقائيًا:

1. وقت إضافة السجل إلى قاعدة البيانات ،
   
2. وقت الحدث.
   

هذه أوقات مختلفة ، مهما كانت مسلية.

لنفترض أن إيفان إيفانوفيتش توفي في 17 نوفمبر ، وتم إدخال هذا السجل في قاعدة البيانات في 20 نوفمبر - يتم تخزين كل من هذه الأوقات في قواعد البيانات هذه.

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

إذا لم نكن بحاجة مطلقًا إلى حذف أي شيء من قاعدة البيانات على الإطلاق ، فإن قاعدة بياناتنا تكون دائمًا متسقة - هذه قصة مثيرة للاهتمام!

روابط مفيدة

• https://developer.couchbase.com/documentation/server/current/developer-guide/query-consistency.html
• https://martinfowler.com/books/nosql.html
• http://jimwebber.org/2011/02/on-sharding-graph-databases/
• https://docs.mongodb.com/manual/core/document-validation/
• http://www.oreilly.com/pub/e/3847
• https://www.oreilly.com/ideas/data-modeling-with-multi-model-databases
• https://redislabs.com/blog/redis-as-a-json-store/

أخبار

في وقت قريب جدًا ، في 21 يونيو ، سيعقد مؤتمر تارانتول في موسكو - أو لفترة وجيزة T + Conf - مؤتمر ليس فقط حول تارانتول نفسها ، ولكن حول استخدام الحوسبة في الذاكرة بشكل عام .

• يخطط كونستانتين أوسيبوف لإعداد تقرير يفحص فيه بنية الفينيل وقدراته ، والأهم من ذلك ، آليات الضبط ومراقبة الأداء الخاصة بهذا المحرك بأكبر قدر ممكن من الاتساق والتفصيل.
• Vladimir Perepelitsa بتنسيق تعليمي ، يريد أن يظهر أن Tarantool هي قاعدة بيانات ذات إمكانات كبيرة للاستخدام كخادم تطبيق.
• فلاديسلاف زايتسيف من الاقتراب من هذا الموضوع من جانبه - من جانب إنترنت الأشياء وإخباره ، على وجه الخصوص ، لماذا نظام التحكم في إنترنت الأشياء.