يا هبر.
اسمي ميشا بوتريموف، أود أن أخبركم قليلاً عن كاساندرا. ستكون قصتي مفيدة لأولئك الذين لم يسبق لهم أن واجهوا قواعد بيانات NoSQL - فهي تحتوي على الكثير من ميزات التنفيذ والمزالق التي تحتاج إلى معرفتها. وإذا لم ترَ أي شيء آخر غير Oracle أو أي قاعدة بيانات علائقية أخرى، فهذه الأشياء ستنقذ حياتك.
ما هو الشيء الجيد في كاساندرا؟ إنها قاعدة بيانات NoSQL مصممة بدون نقطة فشل واحدة ويمكن تحجيمها بشكل جيد. إذا كنت بحاجة إلى إضافة بضعة تيرابايت لبعض قواعد البيانات، فما عليك سوى إضافة العقد إلى الحلقة. توسيعه إلى مركز بيانات آخر؟ إضافة العقد إلى الكتلة. زيادة RPS المعالجة؟ إضافة العقد إلى الكتلة. إنه يعمل في الاتجاه المعاكس أيضًا.
ما الذي تجيده أيضًا؟ يتعلق الأمر بالتعامل مع الكثير من الطلبات. ولكن كم هو الكثير؟ 10، 20، 30، 40 ألف طلب في الثانية ليس كثيرًا. 100 ألف طلب تسجيل في الثانية أيضًا. هناك شركات قالت إنها تستقبل 2 مليون طلب في الثانية. ربما سيتعين عليهم تصديق ذلك.
ومن حيث المبدأ، لدى كاساندرا اختلاف كبير عن البيانات العلائقية - فهي لا تشبهها على الإطلاق. وهذا مهم جدًا أن تتذكره.
ليس كل ما يبدو متشابهًا يعمل بنفس الطريقة
ذات مرة جاء إلي أحد الزملاء وسألني: "هذه لغة استعلام CQL Cassandra، ولها عبارة محددة، ولها مكان، ولها و. أكتب رسائل ولا ينجح الأمر. لماذا؟". إن التعامل مع كاساندرا وكأنها قاعدة بيانات علائقية هي الطريقة المثالية للانتحار العنيف. وأنا لا أروج له، فهو محظور في روسيا. عليك فقط تصميم شيء خاطئ.
على سبيل المثال، يأتي إلينا عميل ويقول: "دعونا نبني قاعدة بيانات للمسلسلات التلفزيونية، أو قاعدة بيانات لدليل الوصفات". سيكون لدينا أطباق طعام هناك أو قائمة بالمسلسلات التلفزيونية والممثلين فيها. نقول بفرح: "هيا بنا!" فقط أرسل وحدتي بايت، واثنين من الإشارات، وستكون قد انتهيت، وسيعمل كل شيء بسرعة كبيرة وبشكل موثوق. وكل شيء على ما يرام حتى يأتي العملاء ويقولون إن ربات البيوت يحلن أيضًا المشكلة المعاكسة: لديهم قائمة بالمنتجات، ويريدون معرفة الطبق الذي يريدون طهيه. أنت ميت.
وذلك لأن Cassandra عبارة عن قاعدة بيانات مختلطة: فهي توفر في نفس الوقت قيمة أساسية وتخزن البيانات في أعمدة واسعة. في Java أو Kotlin، يمكن وصفها على النحو التالي:
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
أي خريطة تحتوي أيضًا على خريطة مرتبة. المفتاح الأول لهذه الخريطة هو مفتاح الصف أو مفتاح التقسيم - مفتاح التقسيم. المفتاح الثاني، وهو مفتاح الخريطة التي تم فرزها بالفعل، هو مفتاح التجميع.
لتوضيح توزيع قاعدة البيانات، دعونا نرسم ثلاث عقد. أنت الآن بحاجة إلى فهم كيفية تحليل البيانات إلى العقد. لأنه إذا حشرنا كل شيء في واحد (بالمناسبة، يمكن أن يكون هناك ألف، أو ألفين، أو خمسة - أي عدد تريده)، فإن الأمر لا يتعلق بالتوزيع حقًا. لذلك، نحن بحاجة إلى دالة رياضية تقوم بإرجاع رقم. مجرد رقم، عدد صحيح طويل يقع ضمن نطاق ما. وسيكون لدينا عقدة واحدة مسؤولة عن نطاق واحد، والثانية عن الثانية، والرقمية عن النطاق n.
يتم أخذ هذا الرقم باستخدام دالة التجزئة، والتي يتم تطبيقها على ما نسميه مفتاح التقسيم. هذا هو العمود المحدد في توجيه المفتاح الأساسي، وهذا هو العمود الذي سيكون المفتاح الأول والأكثر أساسية للخريطة. فهو يحدد العقدة التي ستتلقى البيانات. يتم إنشاء جدول في Cassandra بنفس بناء الجملة تقريبًا كما في SQL:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
يتكون المفتاح الأساسي في هذه الحالة من عمود واحد، وهو أيضًا مفتاح التقسيم.
كيف سيكون أداء مستخدمينا؟ سيذهب البعض إلى عقدة معينة، والبعض الآخر إلى عقدة أخرى، والبعض الآخر إلى عقدة ثالثة. والنتيجة هي جدول تجزئة عادي، يُعرف أيضًا باسم الخريطة، ويُعرف أيضًا باسم القاموس في بايثون، أو بنية قيمة أساسية بسيطة يمكننا من خلالها قراءة جميع القيم وقراءتها وكتابتها بواسطة المفتاح.
حدد: عندما يتحول السماح بالتصفية إلى فحص كامل، أو ما لا يجب فعله
لنكتب بعض العبارة المختارة: select * from users where, userid = . اتضح كما هو الحال في Oracle: نكتب التحديد، ونحدد الشروط وكل شيء يعمل، ويحصل عليه المستخدمون. ولكن إذا حددت، على سبيل المثال، مستخدمًا له سنة ميلاد معينة، فستشتكي كاساندرا من عدم قدرتها على تلبية الطلب. لأنها لا تعرف أي شيء على الإطلاق عن كيفية توزيع البيانات حول سنة الميلاد - لديها عمود واحد فقط مُشار إليه كمفتاح. ثم تقول: "حسنًا، لا يزال بإمكاني تلبية هذا الطلب. إضافة السماح بالتصفية." نضيف التوجيه، كل شيء يعمل. وفي هذه اللحظة يحدث شيء فظيع.
عندما نجري على بيانات الاختبار، كل شيء على ما يرام. وعندما تقوم بتنفيذ استعلام في الإنتاج، حيث لدينا، على سبيل المثال، 4 ملايين سجل، فإن كل شيء ليس جيدًا بالنسبة لنا. لأن السماح بالتصفية هو توجيه يسمح لـ Cassandra بجمع كل البيانات من هذا الجدول من جميع العقد، وجميع مراكز البيانات (إذا كان هناك الكثير منها في هذه المجموعة)، وبعد ذلك فقط قم بتصفيتها. هذا نظير للفحص الكامل، ومن غير المرجح أن يكون أي شخص مسرورًا به.
إذا كنا نحتاج فقط إلى المستخدمين عن طريق الهوية، فلا بأس بذلك. لكن في بعض الأحيان نحتاج إلى كتابة استفسارات أخرى وفرض قيود أخرى على الاختيار. لذلك، نتذكر: هذه كلها خريطة بها مفتاح تقسيم، ولكن بداخلها خريطة مرتبة.
ولديها أيضًا مفتاح، والذي نسميه مفتاح التجميع. هذا المفتاح، والذي يتكون بدوره من الأعمدة التي نختارها، والتي من خلالها تفهم كاساندرا كيفية فرز بياناتها فعليًا وستكون موجودة في كل عقدة. وهذا يعني أنه بالنسبة لبعض مفاتيح التقسيم، سيخبرك مفتاح التجميع بالضبط بكيفية دفع البيانات إلى هذه الشجرة، وفي أي مكان ستأخذها هناك.
هذه في الواقع شجرة، يتم استدعاء المقارنة ببساطة هناك، والتي نمرر إليها مجموعة معينة من الأعمدة في شكل كائن، ويتم تحديدها أيضًا كقائمة من الأعمدة.
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
انتبه إلى توجيه المفتاح الأساسي؛ وسيطته الأولى (في حالتنا، السنة) هي دائمًا مفتاح التقسيم. يمكن أن تتكون من عمود واحد أو أكثر، لا يهم. إذا كان هناك عدة أعمدة، فيجب إزالتها بين قوسين مرة أخرى حتى يفهم المعالج المسبق للغة أن هذا هو المفتاح الأساسي، وخلفه جميع الأعمدة الأخرى هي مفتاح التجميع. وفي هذه الحالة، سيتم نقلها في المقارنة بالترتيب الذي تظهر به. أي أن العمود الأول أكثر أهمية، والثاني أقل أهمية، وهكذا. كيف نكتب، على سبيل المثال، يساوي الحقول لفئات البيانات: نحن ندرج الحقول، ونكتب لها أي منها أكبر وأيها أصغر. في Cassandra، هذه هي، نسبيًا، حقول فئة البيانات، والتي سيتم تطبيق المعادلات المكتوبة عليها.
وضعنا الفرز وفرض القيود
عليك أن تتذكر أن ترتيب الفرز (تنازلي، تصاعدي، أيًا كان) يتم تعيينه في نفس اللحظة التي يتم فيها إنشاء المفتاح، ولا يمكن تغييره لاحقًا. فهو يحدد فعليًا كيفية فرز البيانات وكيفية تخزينها. إذا كنت بحاجة إلى تغيير مفتاح التجميع أو ترتيب الفرز، فسيتعين عليك إنشاء جدول جديد ونقل البيانات إليه. هذا لن ينجح مع الموجود.
لقد ملأنا طاولتنا بالمستخدمين ورأينا أنهم وقعوا في حلقة، أولاً حسب سنة الميلاد، ثم داخل كل عقدة حسب الراتب ومعرف المستخدم. الآن يمكننا الاختيار عن طريق فرض القيود.
يظهر عاملنا مرة أخرى where, and، ونحصل على المستخدمين، وكل شيء على ما يرام مرة أخرى. ولكن إذا حاولنا استخدام جزء فقط من مفتاح التجميع، وجزء أقل أهمية، فسوف تشكو كاساندرا على الفور من عدم قدرتها على العثور على المكان في خريطتنا حيث يوجد هذا الكائن، الذي يحتوي على هذه الحقول للمقارنة الفارغة، وهذا الكائن لقد تم تعيين ذلك للتو، - حيث يرقد. سيتعين علي سحب جميع البيانات من هذه العقدة مرة أخرى وتصفيتها. وهذا نظير للمسح الكامل داخل العقدة، وهذا أمر سيء.
في أي موقف غير واضح، قم بإنشاء جدول جديد
إذا أردنا أن نكون قادرين على استهداف المستخدمين حسب الهوية، أو العمر، أو الراتب، فماذا يجب أن نفعل؟ لا شئ. مجرد استخدام جدولين. إذا كنت تريد الوصول إلى المستخدمين بثلاث طرق مختلفة، فسيكون هناك ثلاثة جداول. لقد ولت الأيام التي قمنا فيها بتوفير المساحة على المسمار. هذا هو أرخص الموارد. ويكلف أقل بكثير من زمن الاستجابة، الأمر الذي يمكن أن يكون ضارًا للمستخدم. إنه لمن دواعي سروري أن يحصل المستخدم على شيء ما في ثانية واحدة بدلاً من 10 دقائق.
نحن نستبدل المساحة غير الضرورية والبيانات غير الطبيعية بالقدرة على التوسع بشكل جيد والعمل بشكل موثوق. بعد كل شيء، في الواقع، فإن المجموعة التي تتكون من ثلاثة مراكز بيانات، كل منها يحتوي على خمس عقد، مع مستوى مقبول من الحفاظ على البيانات (عند فقدان أي شيء)، قادرة على النجاة من موت مركز بيانات واحد تمامًا. وعقدتين أخريين في كل من العقدتين المتبقيتين. وفقط بعد ذلك تبدأ المشاكل. يعد هذا تكرارًا جيدًا جدًا، فهو يستحق بضعة محركات أقراص ومعالجات SSD إضافية. لذلك، من أجل استخدام Cassandra، وهو ليس SQL أبدًا، حيث لا توجد علاقات، مفاتيح خارجية، تحتاج إلى معرفة قواعد بسيطة.
نحن نصمم كل شيء حسب طلبك. الشيء الرئيسي ليس البيانات، ولكن كيف سيعمل التطبيق معها. إذا كان يحتاج إلى تلقي بيانات مختلفة بطرق مختلفة أو نفس البيانات بطرق مختلفة، فيجب علينا وضعها بطريقة مناسبة للتطبيق. وإلا فسوف نفشل في الفحص الكامل ولن تمنحنا كاساندرا أي ميزة.
إن إلغاء تطبيع البيانات هو القاعدة. لقد نسينا النماذج العادية، ولم يعد لدينا قواعد بيانات علائقية. إذا وضعنا شيئًا ما 100 مرة، فسوف يستلقي 100 مرة. لا يزال أرخص من التوقف.
نختار مفاتيح التقسيم بحيث يتم توزيعها بشكل طبيعي. لا نريد أن يقع تجزئة مفاتيحنا في نطاق ضيق واحد. أي أن سنة الميلاد في المثال أعلاه هي مثال سيء. بتعبير أدق، من الجيد أن يتم توزيع مستخدمينا بشكل طبيعي حسب سنة الميلاد، وسيئة إذا كنا نتحدث عن طلاب الصف الخامس - لن يكون التقسيم هناك جيدا جدا.
يتم تحديد الفرز مرة واحدة في مرحلة إنشاء مفتاح التجميع. إذا كانت هناك حاجة للتغيير، فسيتعين علينا تحديث جدولنا بمفتاح مختلف.
والأهم من ذلك: إذا أردنا استرجاع نفس البيانات بـ 100 طريقة مختلفة، فسيكون لدينا 100 جدول مختلف.
المصدر: www.habr.com