المشاركة القصوى:قاعدة بيانات SQLite واحدة لكل مستخدم

Question

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

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

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

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

عندما ينمو التطبيق ليتجاوز خادمًا واحدًا، يمكنني ربط الخوادم معًا على مستوى نظام الملفات باستخدام GlusterFS وتشغيل التطبيق دون تغيير، أو إعداد نظام وكيل SQLite بسيط يسمح لكل خادم بمعالجة ملفات sqlite في الخوادم المجاورة.

ستكون مشكلات التزامن في حدها الأدنى لأن كل طلب HTTP سوف يلمس فقط ملفًا واحدًا أو اثنين من ملفات قاعدة البيانات في المرة الواحدة، من بين الآلاف، ولا يقوم SQLite إلا بحظر عمليات القراءة على أي حال.

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

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

تتطلب معظم ميزات تطبيقي الوصول إلى جزء واحد أو قسمين فقط لكل طلب، ولكن هناك جزء واحد على وجه الخصوص يتطلب تنفيذ استعلام بسيط على 10 إلى 100 جزء مختلف من أصل 256، اعتمادًا على المستخدم.تشير الاختبارات إلى أن الأمر سيستغرق حوالي 0.02 ثانية، أو أقل، إذا تم تخزين كافة البيانات مؤقتًا في ذاكرة الوصول العشوائي (RAM).أعتقد أنني أستطيع العيش مع ذلك!

تحديث 2.0 لقد قمت بنقل التطبيق إلى MySQL/InnoDB وتمكنت من الحصول على نفس الأداء تقريبًا للطلبات العادية، ولكن بالنسبة لهذا الطلب الذي يتطلب المشي الجزئي، فإن innodb أسرع بـ 4-5 مرات.لهذا السبب، ولسبب آخر، سأقوم بإسقاط هذه البنية، ولكن أتمنى أن يجد شخص ما في مكان ما استخدامًا لها... شكرًا.

Answer 1

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

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

قد تحتاج أيضًا إلى الانتباه إلى موارد نظام الملفات - SQLite رائع ورائع وسريع وما إلى ذلك - ولكنك تحصل على بعض فوائد التخزين المؤقت والكتابة عند استخدام "قاعدة بيانات قياسية" (أي.MySQL، وPostgreSQL، وما إلى ذلك) نظرًا لكيفية تصميمها.في تصميمك المقترح، ستفتقد بعضًا من ذلك.

Answer 2

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

Answer 3

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

الحل المحتمل لهذه المشكلة هو إنشاء "قطع صغيرة"تتكون من 1024 قاعدة بيانات SQLite تحتوي على ما يصل إلى 100 مستخدم لكل منهما.سيكون هذا أكثر كفاءة من نهج قاعدة البيانات لكل مستخدم، لأن البيانات يتم تجميعها بشكل أكثر كفاءة.وأخف من نهج خادم قاعدة بيانات Innodb، لأننا نستخدم Sqlite.

سيكون التزامن جيدًا أيضًا، لكن الاستعلامات ستكون أقل أناقة (shard_id yuckiness).ماذا تعتقد؟

Answer 4

http://freshmeat.net/projects/sphivedb

SPHiveDB هو خادم لقاعدة بيانات sqlite.يستخدم JSON-RPC عبر HTTP لكشف واجهة الشبكة لاستخدام قاعدة بيانات SQLite.وهو يدعم دمج قواعد بيانات SQLite متعددة في ملف واحد.كما أنه يدعم استخدام ملفات متعددة.إنه مصمم لمخطط التجزئة الشديد - قاعدة بيانات SQLite واحدة لكل مستخدم.

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

لا يكفي لجعل الأمر صعبًا، بل يكفي لجعله غير تافه.