خدعة غريبة واحدة لتسريع فرق الميزات!
كبار المهندسين يكرهون هذا!
Photo by Danny Howe on Unsplash
جدول المحتويات
عند تصميم نظام أو ميزة جديدة، من السهل أن تنشغل بتصميم المخطط (schema). في هذه المقالة سأشاركك حيلة بسيطة أثبتت جدواها على مدار مسيرتي المهنية.
جرب أبسط استمرارية بيانات ممكنة عند تصميم نظام أو ميزة جديدة.
كثيرًا ما أرى فرقًا تلجأ إلى SQL أو MongoDB كخيار وحيد لتخزين البيانات. صحيح أنه لا أحد سيُطرد لاختياره SQL. لكن ماذا لو أخبرتك أن هناك طريقة أبسط وأسرع وأرخص للبدء؟
قد يكون مخزن المفاتيح (KV) أو مخزن القيمة-المفتاح هو كل ما تحتاجه. شيء مثل Redis أو S3.
ليس دائمًا الخيار الصحيح، لكن ربما أكثر مما تتصور.
يمكن لطبقة تخزين بسيطة أن تسرع بشكل معتدل التطوير المبكر عن طريق إعادة استخدام كود طبقة البيانات وتجنب التكاليف المرتبطة بالتغيير في تصميم المخطط والترحيلات. التغيير سيحدث على أي حال؛ دع الكود يتعامل معه لأطول فترة ممكنة. الأفضل تجنب التعامل مع التغييرات في مكانين.
من المحتمل تحقيق مكاسب في الأداء لأن عمليات البحث باستخدام key محسّنة بشكل كبير، ويمكن أن تستفيد عمليات الكتابة من التحديثات المجمعة.
التفكير في المفاتيح
قد يبدو التصميم باستخدام نمط المفتاح-القيمة لأول مرة غريبًا، خاصة إذا كنت معتادًا على تصميم الأنظمة باستخدام التسلسلات الهرمية للكائنات أو مخططات العلاقات بين الكيانات وتنفيذها مباشرة في SQL.
ربما تكون قد استخدمت أنماط المفتاح-القيمة من قبل! فهي موجودة في كل مكان، من الإعدادات وعناوين URL إلى تخزين الكائنات على غرار S3! في كل مرة تتعامل فيها مع البيانات عبر قيمة ID فريدة، خمن ماذا؟ نمط مفتاح-قيمة آخر! (وإن لم يكن بالضرورة مخزن KV.)
التصميم باستخدام المفاتيح
يمكن تمثيل جميع البيانات تقريبًا باستخدام أنماط KV. (في الواقع، العديد من قواعد البيانات عالية المستوى تُبنى على أنماط KV منخفضة المستوى.) دعنا نلقي نظرة على بعض الأمثلة:
user/123 {id: 123, ...}user/123/block ['user/456', 'user/789']user/123/groups ['admin', 'staff']user/420/friends ['user/456', 'user/789']
group/admin {user: '*:rw'}group/default {user: '*:r'}
product/42/discount/<UUID> {percentOff: '10%'}product/42/discount/<UUID> {percentOff: '20%', minTotal: 100.0}ربما لاحظت أن ID غالبًا ما يكون مفتاحًا بحد ذاته! هذا نمط شائع في مخازن KV. غالبًا ما يكون المفتاح مركبًا من نوع الكيان والمعرّف الفريد. (مثل user/123، user:456)
KV كرسوم بيانية وأشجار؟
قد يكون من المفيد تمثيل هياكل البيانات المعقدة مثل الرسوم البيانية أو الأشجار باستخدام أنماط KV. (مرة أخرى، عناوين URL الخاصة بـ REST هي مثال رائع على ذلك.)
التسلسل الهرمي للمفاتيح (user/420 -> user/420/friends) يُشفّر بشكل طبيعي علاقة بيانية بين user وأصدقائهم friends.
هذه طريقة سريعة ورخيصة لتسلسل هياكل البيانات البيانية. خاصة إذا كنت لا تحتاج إلى تعقيد قاعدة بيانات بيانية (مثل Neo4j).
متى تستخدم أنماط KV
- عندما تحتاج إلى نطاق واسع جدًا (مليارات أو حتى تريليونات من أزواج KV).
- عندما تصل إلى البيانات بشكل أساسي عبر مفتاح فريد.
- عندما تحتاج إلى هياكل بيانات بسيطة.
- عندما تكون لديك بيانات ذات تسلسل هرمي أو رسم بياني أو هيكل شجري.
متى تتجنب أنماط KV
لا تخزّن أشياءً مثل تعليقات المدونة في زوج KV واحد. على سبيل المثال، post/666 -> {comments: [...كثير جدًا...]}. بدلاً من ذلك، قد تستخدم post/666/comments/1 أو post/666/comments/<UUID>، إلخ. أو استخدم جدول SQL.
- عندما تحتاج إلى البحث حسب الخصائص (وليس المفتاح أو المعرف) في مجموعة بياناتك.
- عندما تحتاج إلى JOIN البيانات عبر كيانات متعددة.
- عندما تحتاج إلى فرض قيود أو علاقات معقدة.
عندما تحتاج إلى أكثر من KV
مع تطور متطلبات المشروع بشكل طبيعي، قد تحتاج إلى القيام بأكثر مما يدعمه مخزن KV الخاص بك. عند هذه النقطة، ستحتاج إلى التفكير في الترحيل إلى مخزن بيانات أكثر تعقيدًا.
الخبر السار هو أن ترحيل مخزن KV واحد إلى SQL أسهل نسبيًا من ترحيل مخطط SQL معقد إلى مخزن KV. (مع جداول متعددة، وفهارس، وقيود، إلخ.) لقد قمت بذلك عدة مرات باستخدام سكريبت من 50 سطرًا.
من الناحية العملية، وجدت أن جودة تصاميم SQL تكون أعلى إذا بدأت بنمط KV أولاً. إنه يجبرك على التفكير في البيانات بطريقة مختلفة، وفهم بالضبط ما تحتاجه حقًا من SQL.
الخطوات التالية
أفضل طريقة للتعلم هي التجربة! إذا كنت مهتمًا باستكشاف هذا النمط أكثر، أوصي ببناء أشياء باستخدام Redis أو DynamoDB أو S3. جميعها مخازن KV ممتازة بمقايضات مختلفة.
خدمة الحقائق - مشروع مرجعي
اطّلع على مشروعي مفتوح المصدر “خدمة الحقائق”، مشروع مرجعي على GitHub.
إنها واجهة RESTful قائمة بذاتها تنفذ خدمة بيانات KV.
تتضمن العديد من محولات البيانات. بما في ذلك Postgres وRedis وDynamoDB وFirestore وCassandra! (مكتملة بـ أوامر Docker للبدء بسرعة.)
خدمة الحقائق مخصصة لتكون مشروعًا بدائيًا وتعليميًا، قم بعمل fork وابنِ خدمة بيانات KV الخاصة بك!
الخاتمة
أتمنى أن تكون هذه المقالة مفيدة لك! إذا كان لديك أي أسئلة أو تعليقات، فلا تتردد في التعليق أو مناداتي بـ @ على Twitter.