الكاتب | sanhuazhang

تحرير | الرماد

في GMTC 2017 المؤتمر العالمي للجوال في أمس، الروبوت مهندس كبير من الحرف الصغيرة وJUNWEI للقيام قناة الصغرى تقاسم سكليتي تلف قاعدة البيانات ممارسة الانتعاش، وأعلن عبر منصة إطار المحمول WCDB قاعدة بيانات مفتوحة المصدر في الجمعية العامة.

هنا نأتي

اليوم، WCDB (قاعدة بيانات WeChat) المراجعة النهائية من قبل الشركة، على الجميع أن إلكتروني الجزئي حصة تينسنت باعتبارها مكونات مفتوحة المصدر.

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

استكشاف بهم

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

مع دعم لمنصة أندرويد يوفر SDK الكافي، واستخدام NDK إزعاج التنمية، الانتقاء الطبيعي تطوير واجهة API النظام.

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

أوراق دائرة الرقابة الداخلية

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

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

كود الغراء

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

غير فعال

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

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

SQL حقن

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

حقن SQL وعادة ما يستخدم خصائص سلسلة سلسلة SQL، مع الرموز الخاصة SQL مسبقا اقتطاع، لتحقيق غرض أداء SQL الآخرين. تخيل هذا قطعة من التعليمات البرمجية:

هذه المجموعة هي بسيطة جدا، ومحتوى الرسالة هو لإدراجها في قاعدة البيانات. لنفترض أن الطرف الآخر لإرسال مثل هذه الرسالة: ')؛ حذف من الرسالة؛ -، ثم وهذا سيتم اقتطاع إلى SQL ثلاثة أجزاء:

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

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

كيتون يترددون

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

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

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

هل آن الأوان النسخ الاحتياطي للبيانات المستخدم، لا يمكنك استخدام بريد إلكتروني الصغير؟ غير واقعي واضح.

لذلك، ونحن دعونا الانتهاء WCDB تطور.

التزامن الموضوع

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

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

عن تفاصيل التحسين، ويمكن أن نشير إلى مشاركة قبل --- .

حزمة SQL

WCDB التي كتبها التغليف الكلي، بحيث أن هذا النوع من تعريف الحقل الخدمة وداخل الطبقة. WCDB بواسطة ماكرو يوفر هذه المعلومات في CRUD التالية. وأصبح هذا WCDB الشكل ORM.

ثم نحن شددت واجهة، وتوفير سوى واجهة معظم CRUD الأساسية لا يدعم SQL مخصصة. في الوقت نفسه، ونحن نستخدم C ++ ميزات القالب من SQL تجميعها مخبأة في استدعاء دالة، وبنيت في الحقن المضادة للSQL. وأصبح هذا النموذج WINQ (WCDB لغة الاستعلام المتكاملة) هو.

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

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

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

"رجل، دائرة أصدقائي في حاجة للعثور على أقرب الرسائل عشرة، بالإضافة إلى واجهات يهتفون؟"

"المتأنق، تحتاج الاتصالات إلى أن يتم تجميع الاستعلام، واجهات إضافة الانشوده؟"

"الرجل، بالإضافة إلى واجهات يهتفون؟"

"المتأنق ..."

وأضاف I جيدا، وليس الرجل، وهذا هو الاحتياجات الخاصة. . .

WINQ

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

قواعد النحو WINQ SQL المستندة إلى تحقيقه، يمكن البيانات SQL حتى معقدة جدا لا الهروب من هذا الحكم.

وفي الوقت نفسه، أيسر مبسطة وأكثر وضوحا.

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

التشفير والتطور على الروبوت

عندما دائرة الرقابة الداخلية على جهود التنمية والعمارة، والروبوت واجه مشاكل أخرى.

في الروبوت عصر الإصدار 2.x، لأن النظام هو الكمال، العديد من مستخدمي الهواتف النقالة اختيار لتخصيص هواتفهم من قبل الجذر والفرشاة. بعد الجذر من المستخدمين والبرامج الخبيثة يمكن قراءة البيانات من أي APP التعسفي، من أجل النظر في أمن البيانات، قررت الروبوت لإدخال لSQLCipher قاعدة بيانات مشفرة.

التشفير SQLCipher

SQLCipher الاستفادة الكاملة من AES-256 تشفير قاعدة البيانات، ويشمل رأس ملف مجلة / WAL، التي يمكن أن تلبي احتياجات القناة الصغيرة.

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

أحدث إطار الروبوت

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

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

إطار 4.x من الروبوت بنيت في تجمع الاتصال، وإعمال دائرة الرقابة الداخلية WCDB مماثلة، ولكن تنفيذ طبقة جافا، وذلك باستخدام موضوع متزامنة إيقاظ وسائل آلية تحقيق جافا، مقارنة WCDB دائرة الرقابة الداخلية في تجمع الاتصال.

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

WCDB منذ سكليتي بنيت إدراكه الخاصة (أن تكون SQLCipher دقيقة)، أنها عازمة نسخة سكليتي، الذي تجنب المشاكل أن العديد من المطورين.

المؤشر الأمثل

إطار الروبوت الاستعلام عن قاعدة بيانات باستخدام واجهة المؤشر يدعو SQLiteDatabase.query (...) بإرجاع كائن المؤشر، ثم يمكنك استخدام المؤشر اجتياز مجموعة النتائج. يتم تعيين تحقيق أندرويد SDK سكليتي المؤشر 2MB العازلة ذات حجم ثابت، ودعا المؤشر النافذة، لتخزين مجموعة نتائج الاستعلام.

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

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

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

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

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

التعاون

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

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

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

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

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

بعناية

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

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

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

وحتى الآن، والروبوت ودائرة الرقابة الداخلية قاعدة بيانات مع الأفكار والخبرة العملية في مكونات عبر منصة، للتفكير المزيد من الاهتمام من الاتجاه العام للبرنامج. من أجل حصة أفضل النتائج، قاعدة بيانات Android و iOS WCDB مكون بعد إعادة الإعمار من المنطق أعمالهم في منفصلة، مكرسة، مكونات قابلة للتكرار في المنزل من أجل الوصول غيرها من المنتجات.

في نهاية المطاف، WCDB تصبح مكونات مفتوحة المصدر أن ألتقي بكم.

وبالنظر إلى المستقبل

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

مسح شفرة قلق WCDB، ستار الخاص بك هو الدافع الأكبر لدينا!

https://github.com/Tencent/wcdb

نص اليوم الموصى بها

انقر أدناه لقراءة الصورة

خدمة الصغيرة ليست بالضرورة أفضل الممارسات، ونحن لا نريد أن تكون جيدة جدا