كيف تخزن Google جداول طلبات البحث الكبيرة وكيف تؤثر عليك

هذا تثبيت حديث تقني لمدونتنا ، قدمه لك المطور الرائع ، آدم نوكس.

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

تنسيق الملف

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

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

ملف التخزين

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

التسلسل الهرمي للجدول

تمتلك المشاريع القدرة على تخزين مجموعات البيانات ، كل منها قادر على احتواء الجداول. الأمر الكامل للوصول إلى جدول في صيغة Big Query هو [projectname:datasetname.tablename] ، ومع ذلك يمكن اختصاره إلى dataset.tablename إذا كنت تصل إلى الجدول من المشروع الذي تعمل فيه حاليًا.

يمكن أن يكون تقسيم البيانات ذات الصلة إلى جداول منفصلة (على سبيل المثال: حسب التاريخ أو بعد وقوع حدث معين) مفيدًا لإجراء المزيد من الاستعلامات القابلة للصيانة نظرًا لأن الاستعلامات تعمل بشكل عام على جميع الصفوف في الجدول. هذا يعني أنك قد ترغب في إلقاء نظرة على جداول متعددة ، لذلك يوجد شيء يسمى جدول التعريف مخفيًا في كل مجموعة بيانات يمكن الوصول إليه على [projectname:datasetname.__TABLES__] ويحتوي على معلومات حول كل جدول في مجموعة البيانات ويمكن استخدامه لتجميع الجداول من أجل الاستعلام.

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

 SELECT QUANTILES((protoPayload.endTime - protoPayload.startTime), 3) AS responseTimeBucketsInMilliseconds FROM (TABLE_QUERY(appengine_logs, "table_id CONTAINS 'appengine_googleapis_com_request_log' AND creation_time > 1451606400000"))

نظرًا لأنه يتم استخدام عمودين فقط يحتوي كل منهما على أعداد صحيحة ، فلا يزال هذا الاستعلام رخيصًا إلى حد معقول (0.0003 دولار أمريكي) ، على الرغم من أنه يتم الوصول إلى 28+ الذي قيل لي إنه 1.857 تيرابايت من خلال الاستعلام أدناه وسيكلف حوالي 9 دولارات للوصول إلى كل حقل من .

 SELECT SUM(size_bytes)/1000000000 FROM [repcore-prod:appengine_logs.__TABLES__] WHERE table_id CONTAINS 'appengine_googleapis_com_request_log' AND creation_time > 1451606400000

تحديث الملفات

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

طاولات قسمة

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

 SELECT lid FROM [repcore-prod:datastore.LIS] ORDER BY ct

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

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

يمكنك معرفة المزيد عن ديكورات المائدة هنا. على عكس تصفية النتائج باستخدام أوامر مثل LIMIT/WHERE/HAVING/OMIT ، فإن أدوات تزيين الطاولات ستقلل فعليًا من تكلفة الاستعلام عن الجدول لأنه لن يصل إلى البيانات خارج النطاق المحدد. لسوء الحظ ، هذه الطريقة قريبة من عديمة الفائدة في Vendasta لأنه حتى بالنسبة للجداول مثل ListHistoryModel التي نتدفق إليها بالفعل ، ما زلنا نتخلى عن الجدول بأكمله واستبداله كل يوم بنسخة متماثلة إذا كان من NDB مما يعني أن ديكور وقت الجدول سيعمل فقط على ListHistoryModel إذا كنت تهتم فقط بإدخالات اليوم الحالي.

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

نتائج الاستعلام

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