نلفت انتباهكم إلى ترجمة لمقال جوزيف هيلرشتاين المعنون "النظر إلى الوراء في بوستجرس" ، الذي نُشر تحت الإصدار 4.0 من حقوق النشر والتأليف والنشر في Creative Commons ، الإصدار 4.0 (CC-BY 4.0). يحتفظ المؤلفون بالحق في توزيع هذا العمل على مواقع الويب الشخصية والشركات مع وجود رابط مناسب للمصدر.

الترجمة التي أدلى بها ايلينا Indrupskaya. سأضيف من نفسي أن "المبرمج الذي أراد بشدة بناء نظام متعدد الإصدارات" يبدو أنه Vadim Mikheev ، لكننا نعرف جميعًا "المتطوعين من روسيا" الذين أعادوا كتابة GiST.

الشرح

هذا هو تذكر لمشروع بوستجرس ، الذي تم تنفيذه في جامعة كاليفورنيا في بيركلي وبقيادة مايك ستونبراكر من منتصف الثمانينيات إلى منتصف التسعينيات. كواحدة من العديد من المذكرات الشخصية والتاريخية ، تم طلب هذه المقالة للحصول على كتاب [ Bro19 ] عن Stoneringer Turing Award. لذلك ، ينصب تركيز المقال على الدور الرائد لـ Stonebreaker وأفكاره في التصميم. لكن Stonebreaker لم يكن مبرمجًا قط ولم يتدخل في فريق التطوير. كانت قاعدة كود Postgres بمثابة عمل لفريق من الطلاب الرائعين وفي بعض الأحيان مبرمجين جامعيين بدوام كامل يتمتعون بخبرة أكبر قليلاً (وبراتب أكبر قليلاً) من الطلاب. كنت محظوظًا بما فيه الكفاية للانضمام إلى هذا الفريق كطالب في السنوات الأخيرة من المشروع. تلقيت مادة مفيدة لهذه المقالة من بعض الطلاب الأكبر سناً المشاركين في المشروع ، ولكن أي أخطاء أو سهو هي أعمالي. إذا لاحظت أيًا منها ، يرجى الاتصال بي وسأحاول إصلاحها.

1. مقدمة

كان Postgres أكثر المشاريع طموحًا لـ Michael Stonebreak - محاولته الخطيرة لإنشاء نظام قاعدة بيانات عالمي. لمدة عشر سنوات ، أنتج المشروع العديد من المقالات والدكتوراه والأساتذة والشركات أكثر من أي نشاط Stonebreaker آخر. غطى المشروع أيضًا المجال التقني أكثر من أي نظام آخر قام ببنائه. على الرغم من المخاطر الكامنة لهذا الحجم ، أصبحت Postgres أيضًا أنجح قطعة أثرية في البرمجيات التي خرجت من فرق الأبحاث Stonebreaker ، ومساهمتها الرئيسية في المصدر المفتوح. هذا مثال على "النظام الثاني" [ Bro75 ] الذي نجح. في وقت كتابة هذا التقرير ، بعد أكثر من ثلاثين عامًا من بداية المشروع ، يعد نظام PostgreSQL مفتوح المصدر هو نظام قواعد البيانات المفتوح المصدر الأكثر شعبية في العالم ورابع أكثر قواعد البيانات شعبية. وفي الوقت نفسه ، ولدت الشركات التي تم إنشاؤها من Postgres ما مجموعه أكثر من 2.6 مليار دولار (في تكلفة الشراء). بأي حال من الأحوال ، كانت رؤية Postgres Stonebreaker لها صدى كبير دائم.

1.1. الخلفية

حقق Stonebreaker نجاحًا كبيرًا في بداية حياته المهنية مع مشروع أبحاث Ingres Berkeley [ SHWK76 ] وما تلاه من بدء التشغيل ، والتي أسسها مع Larry Rowe و Eugene Wong: Relational Technology، Inc. (RTI).

مع تطور RTI في أوائل الثمانينيات ، بدأ Stonebreaker العمل على دعم أنواع البيانات في قواعد بيانات إدارة قواعد البيانات تجاوزت الأعمدة والأعمدة التقليدية للنموذج الأصلي لعلاقة Codd (Edgar Frank Codd). مثال حافز في ذلك الوقت هو الحاجة إلى قواعد بيانات لدعم أدوات التصميم بمساعدة الكمبيوتر (CAD) لصناعة الالكترونيات الدقيقة. في مقال نشر عام 1983 من قبل Stonebreaker والطلاب ، أوضح براد روبنشتاين وأنتونين جوتمان إلى أي مدى تحتاج هذه الصناعة إلى دعم "أنواع البيانات الجديدة مثل المضلعات والمستطيلات وسلاسل النص ، إلخ" ، " البحث المكاني الفعال "،" قيود السلامة المعقدة "، وكذلك" التسلسلات الهرمية للتصميم والتمثيلات المتعددة "في نفس الهياكل المادية [ SRG83 ]. مع هذا الدافع ، بدأت المجموعة العمل على الفهرسة (بما في ذلك استخدام أشجار جوتمان R للفهرسة المكانية [ Gut84 ]) وعلى إضافة أنواع البيانات المجردة (ADTs) إلى نظام قاعدة البيانات العلائقية. في ذلك الوقت ، كانت ADTs تصميمًا جديدًا وشائعًا للغات البرمجة ، والذي تم تقديمه لأول مرة بواسطة Barbara Liskov ، الحائز على جائزة Turing لجائزة لاحقة ، واستكشفها في برنامج تطبيقات قواعد البيانات من قِبل Lonely Rowe ، متعاون جديد في Stonebreaker. وصف مقال في سجل SIGMOD لعام 1983 [ OFS83 ] Stonebreaker والطلاب جيمس أونج ودينيس فوج دراسة عن هذا المفهوم في ملحق Ingres المسمى ADT-Ingres ، والذي تضمن العديد من مفاهيم العرض التقديمي التي تمت دراستها أكثر عمقا ومع دعم أفضل للنظام في بوستجرس.

2. بوستجرس: معلومات عامة

كما يوحي الاسم ، Postgres هو Post-Ingres: نظام مصمم لأخذ ما يستطيع Ingres فعله وتجاوزه. كانت الميزة المميزة لـ Postgres هي تقديم ما أسماه في النهاية خصائص قاعدة البيانات المتعلقة بالكائنات: دعم مفهوم البرمجة الموجهة للكائنات في نموذج البيانات ولغة الاستعلام التعريفي لنظام قاعدة البيانات. لكن Stonebreaker خططت أيضًا لحل عدد من المشكلات التكنولوجية الأخرى بشكل مستقل عن الدعم الموجه للكائنات في Postgres ، مثل قواعد البيانات النشطة ، والبيانات التي تم إصدارها ، والتخزين العالي ، والتزامن.

تم كتابة مقالتين حول تصميم بوستجرس: وصف للتصميم المبكر في عام 1986 SIGMOD [ SR86 ] ووصف وسيط في CACM 1991 [ SK91 ]. بدأ مشروع بحث بوستجرس تدريجياً في عام 1992 بتأسيس شركة Illustra ، وهي شركة ناشئة ناشئة ، شاركت فيها Stonebreaker ، وطالبة الدراسات العليا وي هونغ ، وأصبحت فيما بعد كبير المبرمجين جيف ميريديث. في القائمة أدناه ، يتم تمييز الفرص المذكورة في مقالة 1986 بعلامة نجمية * ، ويتم تمييز الفرص الواردة في مقالة عام 1991 ، والتي لم تكن موجودة في مقال 1986 ، بخنجر ^† . تم تنفيذ المهام الأخرى المذكورة أدناه في النظام والأبحاث ، ولكن لم يتم العثور عليها في أي مواصفات التصميم. تمت معالجة العديد من هذه الموضوعات في بوستجرس قبل وقت طويل من دراستها أو إعادة اختراعها من قبل الآخرين. في كثير من الحالات ، كان Postgres متقدمًا جدًا على وقته ، واشتعل الاهتمام بالمواضيع لاحقًا ، من منظور حديث.

1. دعم ADT في نظام قاعدة البيانات
   
   • الكائنات المعقدة (مثل البيانات المتداخلة أو بيانات النماذج غير الأولى العادية (النموذج غير العادي الأول - NF2)) *
   • أنواع بيانات الخلاصة المخصصة ووظائفها *
   • طرق الوصول الموسعة لأنواع البيانات الجديدة *
   • معالجة محسّنة للاستعلام مع ميزات معرفة من قبل المستخدم مكلفة
2. قواعد البيانات النشطة وأنظمة القاعدة (المشغلات والتحذيرات) *
   
   • القواعد المنفذة عند إعادة كتابة الطلب ^†
   • القواعد المطبقة كمشغلات لمستوى التسجيل ^†
3. سجل وبناء التخزين والاسترداد
   
   • رمز استرداد التعقيد المنخفض الذي يعامل السجل كبيانات * ، باستخدام ذاكرة غير متطايرة لحالة الالتزام ^†
   • تخزين غير معاد كتابته واستعلامات زمنية ^†
4. دعم تقنيات التخزين العميق الجديدة ، وخاصة الأقراص الضوئية *
5. دعم المعالجات المتعددة والمعالجات المتخصصة *
6. دعم لنماذج اللغة المختلفة
   
   • الحد الأدنى من التغييرات في النموذج العلائقي ودعم استعلامات التعريف *
   • الوصول إلى "المسار السريع" من واجهات برمجة التطبيقات الداخلية لتجاوز لغة الاستعلام ^†
   • تعدد اللغات ^†

سنناقش بإيجاز مساهمة Postgres لكل من هذه العناصر فيما يتعلق بالعمل اللاحق في مجال الحوسبة.

2.1. دعم ADT في نظام قاعدة البيانات

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

2.1.1. كائنات معقدة

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

كان الأسلوب الرئيسي لـ Postgres هو "الجلوس على كرسيين" فيما يتعلق بنمذجة البيانات: تم حفظ جداول Postgres كنوع البيانات "الخارجي الأكثر" ، لكن سمحت للأعمدة بأن يكون لها أنواع "معقدة" ، بما في ذلك المجموعات المتداخلة أو الجداول. كان أحد تطبيقاته الأقل شيوعًا ، التي تم استكشافها أولاً في النموذج الأولي لـ ADT-Ingres ، هو السماح بإعلان عمود نوع الجدول تعريفًا تعريفيًا كتعريف استعلام: "Quel كنوع من البيانات" [ SAHR84 ] (Quel - Ingres Query Language - Approx. .) .

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

في مطلع الألفية ، أصبحت الاستعلامات التعريفية حول الكائنات المتداخلة هاجسًا بحثًا عن شريحة من مجتمع مطوري قواعد البيانات في شكل قواعد بيانات XML. مطلوب لغة XQuery الناتجة (بقيادة Don Chamberlin ، شخصية SQL) لدعم الكائنات المعقدة في لغة Postgel من Postgres. يستخدم XQuery على نطاق واسع ويستخدم على نطاق واسع في الصناعة ، لكنه لم يكن شائعًا بين المستخدمين. اليوم ، يتم إعادة اختبار هذه المفاهيم في مشاريع لغة الاستعلام لنموذج بيانات JSON ، الشائعة في التطبيقات المستندة إلى المستعرض. مثل OQL ، في المجموعات التي رفضت في البداية طلبات البحث التصريحية لصالح البرمجة الموجهة للمطور (حركة "NoSQL") ، غالبًا ما تظهر هذه اللغات كإضافة متأخرة فقط من الرغبة في إضافة استعلامات إلى النظام. في الوقت نفسه ، نظرًا لنمو Postgres على مر السنين (وانتقاله من لغة استعلام Postquel إلى إصدارات SQL التي تفي بالكثير من الأهداف المحددة) ، فقد تضمن دعمًا للبيانات المدمجة ، مثل XML و JSON ، في قواعد بيانات إدارة قواعد البيانات للأغراض العامة ، دون الحاجة إلى أي أو إعادة تصميم كبيرة. يدور الجدل بدرجات متفاوتة من النجاح ، وقد أثبت نهج بوستجرس في توسيع البنية العلائقية مع امتدادات للبيانات المتداخلة نفسه مرارًا وتكرارًا على أنه حالة طبيعية لجميع الأطراف بعد تهدئة الحجج.

2.1.2. أنواع بيانات الخلاصة المخصصة ووظائفها

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

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

Postgres متقدم قليلاً عن وقته في استكشاف هذه الوظيفة. على وجه الخصوص ، في ذلك الوقت ، لم يكن مجتمع أبحاث قاعدة البيانات قلقًا بشكل خاص بشأن الآثار الأمنية لتنزيل التعليمات البرمجية غير الآمنة على الخادم. بدأ هذا ينظر إليه على أنه مشكلة عندما لوحظت التكنولوجيا في هذه الصناعة. جلبت Stonebreaker Postgres إلى السوق عند بدء تشغيل Illustra ، والذي حصلت عليه Informix إلى حد كبير لقدرتها على دعم حزم امتداد DataBlade ، بما في ذلك UDF. أصبحت Informix ، بفضل التكنولوجيا المستندة إلى Postgres وعروض قواعد البيانات المتوازية القوية ، تهديدًا كبيرًا لشركة Oracle. استثمرت Oracle بكثافة في التسويق السلبي للمخاطر المرتبطة بقدرة Informix على تشغيل كود المستخدم "غير الآمن". يعزو البعض موت Informix إلى هذه الحملة ، على الرغم من أن الاحتيال المالي لـ Informix (وما تلاه من محاكمة اتحادية لرئيسه التنفيذي آنذاك) قد تسبب بالتأكيد في مشاكل أكثر خطورة. الآن ، بعد عقود ، يدعم جميع موفري قواعد البيانات الرئيسية الوظائف المخصصة بلغة أو أكثر ، باستخدام تقنيات جديدة للحماية من أعطال الخادم أو تلف البيانات.

وفي الوقت نفسه ، فإن أكوام التكنولوجيا للبيانات الكبيرة في العقد الأول من القرن العشرين ، بما في ذلك ظاهرة MapReduce ، والتي "أفسدت الكثير من الدماء" لصالح Stonebreaker و David DeWitt [ DS08 ] ، هي إعادة تنفيذ فكرة Postgres - رمز المستخدم الذي تم وضعه في الطلب. يبدو أن MapReduce يجمع إلى حد كبير بين أفكار تطوير برامج Postgres والأفكار المتزامنة من أنظمة مثل Gamma و Teradata ، مع بعض الابتكارات البسيطة حول إعادة تشغيل عملية الاستعلام عن أعباء العمل مع إمكانية التوسع القصوى. أظهرت الشركات الناشئة المستندة إلى Postgres و Greenplum و Aster ، حوالي عام 2007 ، أن موازاة Postgres يمكن أن تؤدي إلى شيء أكثر عملية وعملية من MapReduce بالنسبة لمعظم العملاء ، ولكن في عام 2008 ، كان السوق غير جاهز لهذه التكنولوجيا. . في الوقت الحالي ، في عام 2018 ، تتعامل كل حزمة بيانات كبيرة تقريبًا بشكل أساسي مع عبء عمل SQL المتوازي مع UDF ، والذي يشبه جدًا التصميم الذي استخدمه Stonebreaker والفريق لأول مرة في Postgres.

2.1.3. طرق الوصول الموسعة لأنواع البيانات الجديدة

تم تطوير قواعد البيانات العلائقية في نفس وقت إنشاء الأشجار B في أوائل السبعينيات ، وساعدت الأشجار B في إعطاء Codd حلمًا "بالاستقلال عن تخزين البيانات الفعلي": توفر الفهرسة باستخدام الأشجار B مستوى من عدم الاتصال المباشر يعيد تنظيم التخزين الفعلي دون الحاجة إلى تغييرات في التطبيق. كان القيد الرئيسي للأشجار B والهياكل المرتبطة بها هو أنها تدعم فقط البحث عن المساواة والاستفسارات في النطاق أحادي البعد. ولكن ماذا لو كان لديك استعلامات نطاق ثنائية الأبعاد نموذجية للتطبيقات وتطبيقات CAD؟ كانت هذه المشكلة معروفة أثناء Postgres ، وكانت R-tree [ Gut84 ] ، التي طورها Antonin Guttman في مجموعة Stonebreaker ، واحدة من أكثر الفهارس الجديدة الناجحة المصممة لحل هذه المشكلة في الممارسة العملية. ومع ذلك ، فإن اختراع بنية الفهرس لا يحل مشكلة دعم النطاقات متعددة الأبعاد في نظم إدارة قواعد البيانات للأنظمة المعقدة. هناك العديد من الأسئلة. يمكنك بسهولة إضافة طريقة وصول ، مثل R- الأشجار ، إلى DBMS الخاص بك؟ هل يمكنك تعليم المحسن أن يفهم أن طريقة الوصول المحددة ستكون مفيدة لبعض الاستعلامات؟ يمكنك تحقيق الانتعاش الصحيح والوصول في وقت واحد؟ كانت هذه نقطة جريئة للغاية في خطة عمل Postgres: مشكلة في بنية البرنامج تؤثر على معظم محرك قاعدة البيانات ، من المحسن إلى مستوى التخزين ، بالإضافة إلى نظام اليومية والاسترداد. لقد أصبحت Postgres R-trees قوة دافعة قوية ومثالًا رئيسيًا على القابلية للتوسعة الأنيقة لطبقة طريقة الوصول وتكاملها في مُحسِّن الاستعلام. أظهر Postgres ، باستخدام ADT غير الشفاف ، كيفية تسجيل طريقة وصول موصوفة بشكل تجريبي (في هذه الحالة شجرة R) ، وكيف يمكن لمُحسِّن الاستعلام التعرف على تقدير التحديد المجرد (في هذه الحالة ، اختيار النطاق) ومطابقته مع طريقة الوصول الموضحة هذه. تم إيلاء اهتمام أقل للتحكم في الوصول المتزامن في العمل الأولي: عدم وجود ترتيب أحادي الأبعاد للمفاتيح جعل القفل المستخدم في الأشجار B في هذه الحالة غير قابل للتطبيق.

ألهمت الميزات الواعدة لطرق الوصول الموسعة في بوستجرس أحد أول مشاريعي البحثية في نهاية كلية الدراسات العليا: أشجار البحث المعممة - GiST [ HNP95 ] والمفهوم اللاحق لنظرية الفهرسة [ HKM ⁺ 02 ]. قمت بتطبيق GiST في Postgres لفصل دراسي بعد الانتهاء من الدكتوراه ، مما جعل إضافة منطق الفهرسة الجديد إلى Postgres أسهل. أطروحة مارسيل Kornacker من بيركلي (مارسيل Kornacker) حل المشاكل المعقدة من الانتعاش والوصول في وقت واحد ، التي يطرحها "قالب" الموسعة نوع من فهرس GiST [ KMH97 ].

واليوم ، يجمع PostgreSQL بين بنية البرنامج الأصلية لطرق الوصول القابلة للتوسيع (به فهارس B-tree و GiST و SP-GiST و Gin) مع القابلية للتوسعة والوصول التنافسي المكثف لواجهة شجرة البحث العامة (GiST). تدعم فهارس GiST نظام المعلومات الجغرافية PostGIS الشهير المستند إلى PostgreSQL. توفر فهارس الجن دعم فهرسة النص الداخلي في PostgreSQL.

2.1.4. استعلام محسن مع UDFs مكلفة

في أمثلية الاستعلام التقليدية ، كانت المهمة هي تقليل مقدار دفق البيانات (وبالتالي عمليات الإدخال / الإخراج) التي تم إنشاؤها عند معالجة الطلب. هذا يعني أن العبارات التي ترشيح tuples (جلب) جيدة في بداية خطة الاستعلام ، في حين أن العبارات التي يمكن أن تولد tuples جديدة (صلة) تحتاج إلى تنفيذها في وقت لاحق. نتيجةً لذلك ، يقوم "مُحسِّن الاستعلام" "بدفع" مشغلي الجلب أسفل الاتصالات وترتيبها بشكل عشوائي ، مع التركيز بدلاً من ذلك على التحسين الذكي للاتصالات وعمليات الوصول إلى القرص. لقد غيرت UDFs الطريقة: إذا كان لديك UDFs باهظة الثمن في عباراتك النموذجية ، يمكن أن يكون ترتيب تنفيذ UDFs بالغ الأهمية لتحسين الأداء. علاوة على ذلك ، إذا كان UDF في مشغل التحديد يستغرق كثيرًا من الوقت ، فمن الممكن أن يتم التحديد بعد الاتصالات (أي ، يجب أن يكون التحديد "سحب" - اختيار "سحب"). أخذ هذه العوامل في الاعتبار إلى تعقيد مساحة البحث للمحسن. أخذت هذه المشكلة كأول مهمة صعبة في كلية الدراسات العليا ، وانتهى بها الأمر إلى أن أكون موضوع عمل أستاذي مع Stonebreaker في بيركلي وشهادة الدكتوراه في ولاية ويسكونسن تحت إشراف Jeff Naughton ، ولكن بمساعدة دائمة من نصيحة Stonebreaker. كانت Postgres أول DBMS لتخزين تكلفة وانتقائية الوظائف المعرفة من قبل المستخدم في دليل قاعدة البيانات. لقد تعاملنا مع مشكلة التحسين ، حيث توصلنا إلى الترتيب الأمثل لعمليات أخذ العينات ، ثم البديل الأمثل لعمليات أخذ العينات على طول فروع كل شجرة اتصال تم بحثها في بحث الخطة. System R .

, , . , , .

PostgreSQL , . , , , , 2018 . , , , , , . , Postgres .

, , , PostgreSQL (Neil Conway), « » .

2.2.

Postgres . : , « », 1990- .

. — Datalog. « » : , , .

Datalog , - . Datalog — « » . , , .

, , , , . .

(Eric Hanson), Ingres, Postgres. (Spyros Potamianos) PRS2: Postgres Rules System 2. . — . , Ingres. « » « ». , « » « 10%». , « », . ( ), .

PRS2 , , . Postgres (, ) Postgres 3.1 1991 ( ):

 
*        :
*     .        
*  (. .        
* "" )    .   -  
*   () .        .
*   .    .     
*   .  ...
* ,  , ? ,    ,  .
*         , 
*  ... 

Postgres , «» — . PostgreSQL, - .

Postgres « » IBM Starburst MCC HiPAC. SQL . . , , , , « »: , . , - , , , , . , , , , Postgres.

2.3. X

Postgres :

Postgres, - . (write-ahead log — WAL), , . , Ingres 1970- , . [ SK91 ]

, , . , IBM Tandem . : - , , , .

X Postgres . , , , — « » « » . , , — . , «» . : , . Postgres, , , , [ Sto87 ]. Postgres .

« » , , . . , , , , Postgres. Postgres . PostgreSQL .

, PostgreSQL : . , PostgreSQL , Postgres, , Postgres . , (snapshot isolation) Oracle -, .

(Mike Olson) , , B- Postgres B- Berkeley DB, Postgres. . Berkeley DB Sleepycat Corp., () PostgreSQL « ». : , (MVCC), , .

PostgreSQL . Greenplum PostgreSQL . (Matt McCline)— (Jim Gray) Tandem. .

. , NoSQL ( , WAL), (MMDB — main memory databases, ). , . , .

2.4.

في منتصف مشروع Postgres ، وقعت Stonebreaker كأحد المديرين التنفيذيين للحصول على منحة علمية رقمية كبيرة تسمى Project Sequoia. جزء من اقتراح المنحة كان معالجة كميات غير مسبوقة من صور الأقمار الصناعية الرقمية ، والتي تتطلب ما يصل إلى 100 تيرابايت من الذاكرة ، أي كمية أكبر بكثير من البيانات مما كان من الحكمة تخزينها على أقراص مغناطيسية في ذلك الوقت. كان أساس الحل المقترح هو استكشاف فكرة إنشاء DBMS (أي Postgres) ، والتي تسهل الوصول إلى التخزين "العالي" شبه المستقل الذي توفره محركات روبوتية مع التغيير التلقائي للقرص لإدارة مكتبات الأقراص أو الأشرطة البصرية.

هذا أدى إلى العديد من الدراسات المختلفة. كان أحدهم نظام الملفات Inversion - محاولة لتوفير مجموعة من نظام الملفات UNIX عبر نظام إدارة قواعد البيانات العلائقية. في مقال مراجعة لـ سيكويا ، وصفه ستون بريكر بأسلوبه المعتاد في رعاية "تمرين بسيط" [ Sto95 ]. في الواقع ، مايك أولسون ، طالب في ستون بريكر (والمؤسس اللاحق لكلودرا) ، كان مشغولا بهذا منذ عدة سنوات ، وكانت النتيجة النهائية غير واضحة للغاية [ Ols93 ] ولم تنجو من الممارسة.

بعد بضع سنوات ، قاتل Inversion Bill Gates نفس طواحين الهواء في نظام WinFS - وهي محاولة لإعادة إنشاء نظام الملفات الأكثر استخدامًا في العالم عبر النهاية الخلفية لقاعدة بيانات علائقية. تم شحن WinFS في إصدارات تطوير Windows ، ولم يدخل السوق مطلقًا. وصفه غيتس لاحقًا بأنه أكبر خيبة أمل لدى Microsoft.

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

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

2.5. دعم متعدد المعالجات: XPRS

لم يقم Stonebreaker بإنشاء نظام قاعدة بيانات موازية كبير ، لكنه قاد العديد من المناقشات الصعبة في هذا المجال. وثّق مقاله "حالة من أجل لا شيء مشترك" [ Sto86 ] حلولاً معمارية كبيرة الحجم في هذا المجال. قام بتعميم المصطلحات المستخدمة في الصناعة وحير دعم المباني بدون موارد مشتركة ، مثل Gamma و Teradata ، التي تم اكتشافها في 2000 من قبل مجتمع البيانات الكبير.

ومن المفارقات أن أهم مساهمة Stonebreaker في مجال قواعد البيانات المتوازية هي بنية "الذاكرة المشتركة" التي تسمى XPRS ، والتي تعني "eXtended Postgres on RAID and Sprite". في أوائل التسعينيات ، كانت XPRS هي "رابطة العدالة" لأنظمة Berkeley: فهي تجمع بين نظام Postgres Stonebreaker المختصر ، John Ousterhout ، نظام Sprite OS الموزع ، و Dave Patterson و Randy Katz RAID architecture ) كما هو الحال مع العديد من الوظائف بين أعضاء هيئة التدريس ، تم بالفعل تنفيذ مشروع XPRS بواسطة طلاب الدراسات العليا الذين عملوا عليه. اتضح أن المساهمة الرئيسية قدمها وي هونغ ، الذي كتب أطروحة الدكتوراه عن تحسين الاستعلام المتوازي في XPRS. وبالتالي ، كانت المساهمة الرئيسية لـ XPRS في الأدب والصناعة هي تحسين الطلبات المتزامنة دون معالجة المشكلات المرتبطة بـ RAID أو Sprite بشكل كبير.

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

من حيث المبدأ ، "التزامن" "ينفجر" مساحة خطط مُحسِّن الاستعلام ، وضرب الخيارات التقليدية التي اتخذت أثناء تحسين الاستعلام (الوصول إلى البيانات ، خوارزميات الاتصال ، ترتيب الاتصال) بكل الطرق الممكنة لموازنة كل خيار. كانت الفكرة الرئيسية لـ "Wei Hong optimizer" التي دعا إليها Stonebreaker هي تقسيم المشكلة إلى قسمين: إطلاق محسّن الاستعلام التقليدي بروح النظام R لعقدة واحدة ، ثم "موازنة" الخطة الناتجة ، والتخطيط لدرجة التوازي ووضع كل عامل بناءً على التمثيل تكوين البيانات والنظام. هذا النهج هو ارشادي ، ولكن في التزامن يزيد من تكلفة تحسين الاستعلام التقليدي المضافة ، بدلا من مضاعفة.

على الرغم من تطوير مُحسِّن Wei Hong في سياق Postgres ، فقد أصبح النهج القياسي للعديد من مُحسِّن الاستعلام المتزامن في الصناعة.

2.6. دعم لنماذج اللغة المختلفة

من بين اهتمامات Stonebreaker ، التي تم تجديدها مرارًا وتكرارًا منذ عصر Ingres ، كانت واجهة برمجة تطبيقات نظام قاعدة البيانات (API). في محاضراته في سلسلة أنظمة قواعد البيانات ، غالبًا ما كان يدرج لغة GEM كارلو زانيولو كموضوع مهم لفهم مؤيدي نظام قواعد البيانات. أدى هذا الاهتمام باللغة إلى بلا شك إلى شراكة مع لاري رو في بوستجرس ، والتي بدورها أثرت بعمق في تصميم نموذج بيانات بوستجرس ونهجها المتعلق بالعلاقة بين الكائنات. تركز عملهم بشكل أساسي على تطبيقات العمل مع كمية كبيرة من البيانات من المجال التجاري ، بما في ذلك معالجة المعلومات التجارية والتطبيقات الجديدة مثل CAD / CAM و GIS.

كانت إحدى المشكلات التي فرضت على Stonebreaker في ذلك الوقت هي فكرة "إخفاء" الحدود بين بنيات لغة البرمجة ومستودع قاعدة البيانات. استهدفت العديد من المشروعات البحثية المتنافسة والشركات التي تبحث في قواعد البيانات الموجهة للكائنات (OODBs) ما يسمى بـ "فقدان المطابقة" بين لغات البرمجة الموجّهة وجوهًا المهمة مثل Smalltalk و C ++ و Java والعلاقة التوضيحية الإعلانية نموذج. كانت فكرة OODB هي جعل كائنات لغة البرمجة ، إذا رغبت في ذلك ، علامة "دائمة" ومعالجتها تلقائيًا بواسطة نظام إدارة قواعد البيانات المدمج. دعم Postgres تخزين الكائنات المتداخلة وأنواع البيانات المجردة ، لكن واجهته ، بناءً على استعلامات تعريفية بأسلوب علائقي ، افترضت وصولاً غير طبيعي إلى قاعدة البيانات للمبرمج (كان يتطلب استخدام استعلامات تعريفية) ، والتي كانت مكلفة أيضًا (كانت تتطلب التحليل و التحسين). للتنافس مع مزودي OODB ، قدمت Postgres ما يسمى بواجهة المسار السريع: بشكل أساسي C / C ++ API لتخزين قاعدة البيانات الداخلية. سمح هذا بوسترجرس أن يكون متوسط ​​الأداء الأكاديمي OODB ، لكنه لم يحل مشكلة السماح للمبرمجين بلغات مختلفة تجنب مشكلة فقدان الامتثال. بدلاً من ذلك ، وصفت Stonebreaker Postgres بأنها تسمية "مرتبطة بالكائنات" وتجاوزت ببساطة استخدام قواعد البيانات وجوه المنحى كسوق بقيمة مليار دولار. اليوم ، جميع أنظمة قواعد البيانات العلائقية التجارية تقريبًا هي أنظمة قواعد بيانات "مرتبطة بالعناصر".

تحول هذا إلى حل معقول. اليوم ، لا يوجد أي من منتجات OODB في شكله المقصود ، وقد تم تجاهل فكرة "الأشياء الثابتة" في لغات البرمجة إلى حد كبير. على النقيض من ذلك ، فإن استخدام طبقات التعيين المرتبط بالكائنات (ORM) واسع الانتشار ، ويعزز ذلك العمل المبكر مثل Java Hibernate و Ruby on Rails ، مما يجعل من الممكن "تخصيص" قواعد البيانات التعريفية مع أي كائن ضروري تقريبًا لغة برمجة موجهة كمكتبات. يختلف نهج مستوى التطبيق هذا عن كل من قواعد بيانات كائن OODB و Stonebreaker. بالإضافة إلى ذلك ، يتم أيضًا استخدام المستودعات ذات القيمة الأساسية خفيفة الوزن بنجاح في كل من النماذج غير المتعلقة بالمعاملات ونماذج المعاملات. كان مكتشفهم طالبة الدراسات العليا في Stonebreaker Margo Seltzer ، التي عملت في قاعدة بيانات Berkeley DB كجزء من أطروحة الدكتوراه في نفس الوقت مع مجموعة Postgres ، والتي توقعت نمو مستودعات NoSQL الموزعة للقيمة الرئيسية مثل Dynamo و MongoDB و Cassandra.

3. التأثير على البرنامج

3.1. المصدر المفتوح

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

عندما تم تقليص مشروع بحث Postgres ، قام اثنان من طلاب Stonebreaker هما Andrew Yu و Jolly Chen بتعديل محلل النظام لاستبدال لغة Postquel الأصلية بصيغة SQL قابلة للامتداد. كان إصدار Postgres الأول الذي يدعم SQL هو Postgres95 ، وكان يسمى الإصدار التالي PostgreSQL.

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

على الرغم من أن الكثير قد تغير على مدار 25 عامًا ، إلا أن بنية PostgreSQL الأساسية لا تزال تشبه إلى حد كبير إصدارات جامعة بوستجرس في أوائل التسعينيات ، وسيجد المطورون الذين لديهم دراية برمز مصدر بوستجرس الحالي من السهل قراءة شفرة مصدر بوستجرس 3.1 (1991). كل شيء من بنية دليل التعليمات البرمجية المصدر إلى بنية العملية وهياكل البيانات يظل متشابهاً بشكل مفاجئ. كان رمز فريق Postgres في بيركلي العمود الفقري الكبير.

اليوم ، يعد PostgreSQL بلا شك أعلى نظام لإدارة قواعد البيانات مفتوحة المصدر ، وهو يدعم الوظائف التي غالبًا ما لا توجد في المنتجات التجارية. وهو أيضًا (وفقًا لموقع تصنيف مؤثر) هو المصدر المفتوح الأكثر شعبية المفتوح المصدر لنظام إدارة قواعد البيانات في العالم ، ولا يزال تأثيره ينمو: في عامي 2017 و 2018 ، كانت قاعدة البيانات التي تتمتع بشعبية متزايدة في العالم [ DE19c ]. يستخدم PostgreSQL في مجموعة واسعة من الصناعات والمهام ، وهذا ليس مستغربًا ، نظرًا لتركيزه على الفرص الوفيرة.

وفقًا لقواعد DB-Engines ، تعد PostgreSQL اليوم رابعًا من أكثر قواعد البيانات شهرة في العالم ، بعد Oracle و MySQL و MS SQL Server ، وكلها تقدم من قبل شركات محددة (MySQL اشترتها Oracle قبل سنوات عديدة) [ DE19a ]. وتناقش قواعد الترتيب في وصف منهجية التصنيف DB- محركات [ DE19b ].

Heroku هو المزود السحابي SaaS الذي أصبح الآن جزءًا من Salesforce. تم تقديم بوستجرس في Heroku في عام 2010 كقاعدة البيانات الافتراضية لمنصتها. اختار Heroku Postgres للاعتمادية. بدعم من Heroku ، بدأت منصات تطوير التطبيقات الأكبر مثل Ruby on Rails و Python for Django في التوصية Postgres كقاعدة البيانات الافتراضية.

تدعم PostgreSQL اليوم بنية تحتية للإضافة تجعل من السهل إضافة ميزات إضافية إلى النظام من خلال الوظائف المعرفة من قبل المستخدم والتعديلات ذات الصلة. يوجد الآن نظام إيكولوجي لملحقات PostgreSQL ، يشبه مفهوم llustra الخاص بحزم تمديد DataBlade ، ولكن مع شفرة المصدر المفتوح. تتضمن الملحقات الأكثر إثارة للاهتمام ، على سبيل المثال ، مكتبة Apache MADlib للتعلم الآلي في واجهة SQL ومكتبة Citus لتنفيذ الاستعلام الموازي.

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

3.2. التنفيذ التجاري

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

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

لقد ركزت العديد من الجهود التجارية المرتبطة بـ PostgreSQL على ما قد يكون أهم قيودها: القدرة على التوسع في بنية متوازية دون مشاركة الموارد.

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

1. كانت Illustra هي ثاني أكبر شركة ناشئة في Stonebreaker ، تأسست عام 1992 لتسويق Postgres ، حيث أطلقت RTI شركة Ingres في السوق.
   
   كان Illustra بالفعل هو الاسم الثالث المقترح للشركة. مواصلة موضوع اللوحة ، وبالنظر إلى اسم إنجرس ، كان يسمى في الأصل Illustra ميرو. بسبب مشاكل العلامات التجارية ، تم تغيير الاسم إلى Montage ، ولكنه واجه أيضًا مشكلات في العلامات التجارية.
   
   تضمن الفريق المؤسس بعضًا من جوهر فريق Postgres ، بما في ذلك طالب الدراسات العليا الجديد وي هونج ومن ثم كبير المبرمجين جيف ميريديث ، بالإضافة إلى خريجين من إنجرس باولا هاوثورن ومايكل أوبل. انضم مايك أولسون ، طالب الدراسات العليا في بوستجرس ، بعد فترة وجيزة من التأسيس ، وعملت في Illustra لتحسين الميزات باهظة الثمن كجزء من الدكتوراه Illustra : SQL92 , Postquel, Postgres DataBlade — . Illustra Informix 1997 400 . . [ Mon96 ], DataBlade Informix Informix Universal Server.
   
2. Netezza , 1999 , PostgreSQL FPGA. Netezza , 2007 . IBM 1,7 . . [ IBM10 ].
   
3. Greenplum PostgreSQL . 2003 , Greenplum PostgreSQL, API PostgreSQL, API . , Greenplum PostgreSQL , , Orca. Greenplum EMC 2010 300 . . [ Mal10 ], 2012 EMC Greenplum Pivotal. 2015 Pivotal Greenplum Orca . Greenplum Postgres API MADlib SQL [ HRS+12 ]. MADlib Apache. , Greenplum, Apache HAWQ, Pivotal, « » Greenplum (. . PostgreSQL) , Hadoop.
   
4. EnterpriseDB 2004 , PostgreSQL , . EnterpriseDB Advanced Server Oracle, Oracle.
   
5. Aster Data 2005 , . PostgreSQL. Aster , SQL MapReduce. Aster Data Teradata 2011 263 . . [ Sho11 ]. Teradata Aster , - Aster Teradata.
   
6. ParAccel 2006 , PostgreSQL . ParAccel Postgres . 2011 Amazon ParAccel, 2012 AWS Redshift — ParAccel. 2013 ParAccel Actian ( Ingres) , , Actian. AWS Redshift Amazon — Amazon, , , Teradata Oracle Exadata. Postgres .
   
7. CitusDB (CitusDB — ; Citus Data. — . .) 2010 , PostgreSQL . PostgreSQL, 2016 CitusDB API PostgreSQL PostgreSQL. 2016 CitusDB .
   

4.

Postgres, .

, , , Postgres « » (Second System Effect) (Fred Brooks) [ Bro75 ]. , , - . Postgres , , , . , , . — Postgres , . : , . , « » . , , . «-» , «-» .

, , « », , . ( 2001 (). — . .) 2000- « ». , Postgres. , , .

(Ralph Waldo Emerson), « — ».

, « » ( ), , , , , . , . , , - . , . , .

, Postgres, — , . « » PostgreSQL, , . , :

, , , 1995 . Postgres, , . , , , . [ Sto14 ]

, , , , « » . « ». , , , , Postgres. - , : « - ». ( ), .

5.

Postgres , , (Craig Kerstiens) PostgreSQL.

الأدب

• [Bro75] Frederick P Brooks. The mythical man-month, 1975.
• [Bro19] Michael L. Brodie, editor. Making Databases Work. Morgan & Claypool, 2019.
• [DE19a] DB-Engines. DB-Engines ranking, 2019. db-engines.com/en/ranking . (Last accessed January 4, 2019).
• [DE19b] DB-Engines. Method of calculating the scores of the DB-Engines ranking, 2019. db-engines.com/en/ranking_definition (Last accessed January 4, 2019).
• [DE19c] DB-Engines. PostgreSQL is the DBMS of the year 2018, January 2019. db-engines.com/en/blog_post/79 (Last accessed January 4, 2019).
• [DS08] David DeWitt and Michael Stonebraker. Mapreduce: A major step backwards. The Database Column, 1:23, 2008.
• [Gut84] Antonin Guttman. R-trees: A dynamic index structure for spatial searching. In Proceedings of the 1984 ACM SIGMOD International Conference on Management of Data, SIGMOD '84, pages 47–57, New York, NY, USA, 1984. ACM.
• [HKM ⁺ 02] Joseph M. Hellerstein, Elias Koutsoupias, Daniel P. Miranker, Christos H. Papadimitriou, and Vasilis Samoladas. On a model of indexability and its bounds for range queries. J. ACM, 49(1):35–55, January 2002.
• [HNP95] Joseph M. Hellerstein, Jeffrey F. Naughton, and Avi Pfeffer. Generalized search trees for database systems. In Proceedings of the 21th International Conference on Very Large Data Bases, VLDB '95, pages 562–573, San Francisco, CA, USA, 1995. Morgan Kaufmann Publishers Inc.
• [HRS ⁺ 12] Joseph M Hellerstein, Christoper Re, Florian Schoppmann, Daisy Zhe Wang, Eugene Fratkin, Aleksander Gorajek, Kee Siong Ng, Caleb Welton, Xixuan Feng, Kun Li, et al. The MADlib analytics library: or MAD skills, the SQL. Proceedings of the VLDB Endowment, 5(12):1700–1711, 2012.
• [IBM10] IBM to acquire Netezza, September 2010. www-03.ibm.com/press/us/en/pressrelease/32514.wss#release (Last accessed January 22, 2018).
• [KMH97] Marcel Kornacker, C. Mohan, and Joseph M. Hellerstein. Concurrency and recovery in generalized search trees. In Proceedings of the 1997 ACM SIGMOD International Conference on Management of Data, SIGMOD '97, pages 62–72, New York, NY, USA, 1997. ACM.
• [Mal10] Om Malik. Big Data = Big Money: EMC Buys Greenplum. In GigaOm, July 2010. gigaom.com/2010/07/06/emc-buys-greenplum .
• [Mon96] John Monroe. Informix acquires illustra for complex data management. In Federal Computer Week, January 1996.
• [OFS83] James Ong, Dennis Fogg, and Michael Stonebraker. Implementation of data abstraction in the relational database system ingres. ACM Sigmod Record, 14(1):1–14, 1983.
• [Ols93] Michael A. Olson. The design and implementation of the inversion file system. 1993.
• [SAHR84] Michael Stonebraker, Erika Anderson, Eric Hanson, and Brad Rubenstein. Quel as a data type. In Proceedings of the 1984 ACM SIGMOD International Conference on Management of Data, SIGMOD '84, pages 208–214, New York, NY, USA, 1984. ACM.
• [Sho11] Erick Shonfeld. Big pay day for big data. teradata buys aster data for $263 million. In TechCrunch, May 2011. techcrunch.com/2011/03/03/teradata-buys-aster-data-263-million (Last accessed January 22, 2018).
• [SHWK76] Michael Stonebraker, Gerald Held, Eugene Wong, and Peter Kreps. The design and implementation of ingres. ACM Transactions on Database Systems (TODS), 1(3):189–222, 1976.
• [SK91] Michael Stonebraker and Greg Kemnitz. The postgres next generation database management system. Commun. ACM, 34(10):78–92, October 1991.
• [SR86] Michael Stonebraker and Lawrence A. Rowe. The design of postgres. In Proceedings of the 1986 ACM SIGMOD International Conference on Management of Data, SIGMOD '86, pages 340–355, New York, NY, USA, 1986. ACM.
• [SRG83] M Stonebraker, B Rubenstein, and A Guttman. Application of abstract data types and abstract indices to cad bases. IEEE Trans, on Software Engineering, 1983.
• [Sto86] Michael Stonebraker. The case for shared nothing. IEEE Database Eng. Bull., 9(1):4–9, 1986.
• [Sto87] Michael Stonebraker. The design of the postgres storage system. In Proceedings of the 13th International Conference on Very Large Data Bases, VLDB '87, pages 289–300, San Francisco, CA, USA, 1987. Morgan Kaufmann Publishers Inc.
• [Sto95] Michael Stonebraker. An overview of the sequoia 2000 project. Digital Technical Journal, 7(3):39–49, 1995.
• [Sto14] Michael Stonebraker. The land sharks are on the squawk box, 2014. www.acm.org/turing-lecture-stonebraker (Last accessed January 4, 2019).