البحث في الموقع

تستخدِم محركات البحث تقنية بحث النصوص الكاملة (Full-Text Search (FTS للبحث عن نتائج في قاعدة بيانات ما، وهي تقنية مفيدة في تقوية نتائج البحث في مواقع مثل المتاجر الرقمية ومحركات البحث والجرائد وغيرها. ويتلخص ما تفعله FTS في جلب المستندات “documents” وهي وحدات من قواعد البيانات تحتوي بيانات نصية ﻻ تتطابق بشكل كامل مع نصوص البحث، فمثلًا حين يبحث مستخدم ما عن “cats and dogs” فإن التطبيق المزوّد بـتقنية بحث النصوص الكاملة سيُظهر نتائج تحتوي الكلمتين dogs وcats بشكل منفصل، أو بترتيب معكوس “dogs and cats”، أو صور مختلفة من هذه الكلمات (cat أو dog)، وذلك يعطي أفضلية للتطبيقات في تخمين قصد المستخدم وإظهار نتائج بحث مرتبطة بما يريده وبسرعة أكبر. وتسمح أنظمة إدارة قواعد البيانات مثل PostgreSQL بعمليات بحث نصية بشكل جزئي باستخدام بنود LIKE، لكن هذه العمليات تعطي عادةً أداء دون المستوى مع البيانات الكبيرة، كما أنها مقيَّدة بمطابقة مدخلات المستخدم الحرفية، وهذا يعني أن استعلامًا ما أو بحثًا عن بيانات معينة قد ﻻ يعطي أي نتائج، حتى لو كانت هناك مستندات عن معلومات مرتبطة بهذا البحث. أما باستخدام FTS فيمكنك بناء محرك بحث قوي للنصوص دون الحاجة لاعتماديات جديدة على أدوات أكثر تطورًا، وسنستخدم نظام PostgreSQL في هذا المقال لتخزين بيانات تحتوي مقالات لموقع أخبار افتراضي، ثم نتعلم كيف نبحث في قاعدة البيانات باستخدام FTS، واختيار أفضل النتائج فقط. ثم سنقوم ببعض التحسينات في الأداء لعمليات بحث النصوص الكاملة. المتطلبات خادم مثبت عليه أوبنتو 16.04 به مستخدم يملك صلاحيات `sudo`، ﻻ أن يكون هو المستخدم الجذر. خادمPostgreSQL، وسنستخدم نحن قاعدة بيانات ومستخدم باسم `sammy` كمثال. ملاحظة: تأكد أن يكون لديك حزمة postgresql-conrib عبر تنفيذ الأمر التالي في الطرفية: sudo apt-get list postgresql-contrib الخطوة الأولى: إنشاء بيانات وهمية من أجل الشرح سنحتاج إلى بعض البيانات من أجل استخدامها في اختبار إضافة FTS، لكن إن كان لديك جدول به قيم نصية جاهزة فيمكنك أن تنتقل إلى الخطوة التالية مباشرة وتستبدل قيمك بالقيم الموجودة هنا، أما إن لم يكن لديك فاتبع ما يلي: اتصل بقاعدة بيانات PostgreSQL من خلال الخادم الخاص بها، ولن تحتاج كلمة مرور لأنك تتصل من نفس المضيف “host”: sudo -u postgres psql sammy وهذا الأمر سيفتح جلسة PostgreSQL تفاعلية ظاهر بها اسم قاعدة البيانات الذي نعمل عليها -sammy في حالتنا-، فيجب أن ترى =#sammy في محث قاعدة البيانات. أنشئ جدولًا وسمّه news، وسيمثِّل كل مدخل في هذا الجدول مقالًا بعنوان وجزء من المحتوى والكاتب، إضافة إلى معرّف فريد: sammy=# CREATE TABLE news ( sammy=# id SERIAL PRIMARY KEY, sammy=# title TEXT NOT NULL, sammy=# content TEXT NOT NULL, sammy=# author TEXT NOT NULL sammy=# ); إن نظرنا للجدول السابق، فإن id هو معرّف الجدول الأساسي مع النوع الخاص SERIAL المسؤول عن زيادة هذا المعرف بشكل تلقائي للجدول، وذلك معرّف فريد سنتحدث عنه أكثر في الخطوة الثالثة حين ننظر في تحسينات الأداء. واﻵن أضف بعض البيانات للجدول باستخدام أمر INESRT، ستمثل هذه البيانات الوهمية بالأسفل بعض مقالات الأخبار: sammy=# INSERT INTO news (id, title, content, author) VALUES sammy=# (1, 'Pacific Northwest high-speed rail line', 'Currently there are only a few options for traveling the 140 miles between Seattle and Vancouver and none of them are ideal.', 'Greg'), sammy=# (2, 'Hitting the beach was voted the best part of life in the region', 'Exploring tracks and trails was second most popular, followed by visiting the shops and then checking out local parks.', 'Ethan'), sammy=# (3, 'Machine Learning from scratch', 'Bare bones implementations of some of the foundational models and algorithms.', 'Jo'); سنجرب الآن بعض عمليات البحث بما أننا أدخلنا بعض البيانات التي يمكن البحث والاستعلام عنها. الخطوة الثانية: تجهيز المستندات والبحث فيها أول خطوة هنا هي بناء مستند واحد بأعمدة نصوص متعددة من جدول قاعدة البيانات، ثم يمكننا تحويل النتائج بعدها إلى متَّجَه من الكلمات نستخدمه في عمليات البحث. ملاحظة: يستخدم خرج psql في هذا الدليل تهيئة expanded display والتي تعرض كل عمود من الخرج في سطر جديد لتسهيل عرضها على الشاشة. يمكننا تفعيلها كما يلي: sammydb=# \x يجب أن يكون الخرج هكذا: Expanded display is on. سنحتاج أولًا إلى جمع كل الأعمدة معًا باستخدام دالتي التسلسل `||` والتحويل `()to_tsvector` في PostgreSQL: sammy=# SELECT title || '. ' || content as document, to_tsvector(title || '. ' || content) as metadata FROM news WHERE id = 1; سيخرج لنا هذا أول سجلّ كمستند كامل باﻹضافة إلى نسخته التي سنستخدمها في البحث: -[ RECORD 1 ]----------------------------------------------------- document | Pacific Northwest high-speed rail line. Currently there are only a few options for traveling the 140 miles between Seattle and Vancouver and none of them are ideal. metadata | '140':18 'current':8 'high':4 'high-spe':3 'ideal':29 'line':7 'mile':19 'none':25 'northwest':2 'option':14 'pacif':1 'rail':6 'seattl':21 'speed':5 'travel':16 'vancouv':23 ربما تلاحظ أن هناك كلمات أقل في النسخة المحوّلة metadata في الخرج السابق عن النسخة الأصلية document، وبعض الكلمات مختلفة، وكل كلمة لديها فاصلة منقوطة ; ورقم ملحق بها، وذلك ﻷن دالة ()to_tsvector تنسّق كل كلمة كي نستطيع إيجاد صور مختلفة منها، ثم تصنف النتائج أبجديًا، وذلك الرقم هو موضع الكلمة في document، قد تكون هناك مواضع أخرى للكلمة بينها فواصل , إن كانت الكلمة المنسّقة تظهر أكثر من مرة. يمكننا الآن استغلال إمكانيات FTS عبر استخدام هذا المستند المحوّل في البحث عن كلمة “Explorations”: sammy=# SELECT * FROM news WHERE to_tsvector(title || '. ' || content) @@ to_tsquery('Explorations'); وسنقوم الآن بتحليل الدوال والمشغِّلات التي استخدمناها في اﻷمر أعلاه: تترجم دالةُ ()to_tsquery المعاملَ “parameter” -الذي يمكن أن يكون تعديلًا مباشرًا أو طفيفًا في بحث المستخدم- إلى معيار بحث نصي يقلل المدخلات بنفس طريقة ()to_tsvector. وإضافة إلى ذلك فإن الدالة تتيح لك تحديد اللغة التي تريد استخدامها وما إن يجب أن تكون كل الكلمات موجودة في النتائج أو واحدة منهم فقط. ويحدد مشغِّل @@ ما إن كان tsvector مماثلًا لـ tsquery أم لـ tsvector آخر، عبر عرض إحدى نتيجتين (true أو false)، مما يسهّل استخدامه كجزء من معيار WHERE. الخرج: -[ RECORD 1 ]----------------------------------------------------- id | 2 title | Hitting the beach was voted the best part of life in the region content | Exploring tracks and trails was second most popular, followed by visiting the shops and then checking out local parks. author | Ethan أظهرت عمليةُ البحث المستندَ الذي يحتوي كلمة Exploring، رغم أن الكلمة التي بحثنا عنها هي Exploration، أما لو استخدمنا مشغّل LIKE لكنّا حصلنا على نتيجة فارغة. واﻵن بما أننا عرفنا كيفية تجهيز المستندات لها وكيفية هيكلة المستندات، فسننظر في كيفية تحسين أداء FTS. الخطوة الثالثة: تحسين أداء FTS قد يشكّل توليد مستند في كل مرة نستخدم فيها استعلام FTS مشكلة في الأداء إن كنا نستخدم خوادم صغيرة أو بيانات كبيرة. وأحد الحلول الجيدة لهذا الأمر هو توليد المستند المحوّل أثناء إدخال المستند الأصلي وتخزينه مع البيانات الأخرى، وبهذه الطريقة يمكننا استرجاعه باستعلام صغير عوضًا عن توليده في كل مرة. أولًا ننشئ عمودًا إضافيًا اسمه document في جدول news الذي أنشأناه قبل قليل: sammy=# ALTER TABLE news ADD "document" tsvector; سنحتاج الآن أن نستخدم استعلامًا جديدًا ﻹدخال البيانات في الجدول، لكن على عكس الخطوة الثانية، سنحتاج هنا إلى تجهيز المستند المحوّل وإضافته إلى عمود document الجديد: sammy=# INSERT INTO news (id, title, content, author, document) sammy=# VALUES (4, 'Sleep deprivation curing depression', 'Clinicians have long known that there is a strong link between sleep, sunlight and mood.', 'Patel', to_tsvector('Sleep deprivation curing depression' || '. ' || 'Clinicians have long known that there is a strong link between sleep, sunlight and mood.')); تتطلب إضافة عمود جديد إلى الجدول الموجود مسبقًا أن نضيف قيمًا فارغة لعمود document أولًا، وسنحدّثه الآن بالقيم المولَّدة. استخدم أمر UPDATE لإضافة البيانات الناقصة. sammy=# UPDATE news SET document = to_tsvector(title || '. ' || content) WHERE document IS NULL; وهذه الأسطر التي أضفناها إلى جدولنا تحسّن من أداء FTS، لكن قد نواجه مشاكل أخرى في حالة البيانات الكبيرة بسبب أن قاعدة البيانات ﻻ تزال في حاجة إلى فحص الجدول كله ﻹيجاد الأسطر التي توافق مدخلات البحث، وحل هذا أن نستخدم الفهارس “indexes”. فهرس قاعدة البيانات database index هو هيكل بيانات يخزّن البيانات بشكل منفصل من البيانات الأساسية التي تحسّن عمليات استرجاع البيانات، ويتم تحديثها بعد أي تغيّر في محتوى الجدول وﻻ تتكلف إﻻ الكتابة الجديدة ومساحة تخزين صغيرة نسبيًا. وتسمح المساحة الصغيرة وهيكل البيانات المهيّأ جيدًا للفهارس أن تعمل بكفاءة أكبر من استخدام مساحة الجدول لاختيار الاستعلامات. وبشكل عام، فإن الفهارس تسرّع إيجاد قواعد البيانات للصفوف من خلال البحث باستخدام خوارزميات وهياكل بيانات خاصة. ويمتاز نظام PostgreSQL بأن به عدة أنواع من الفهارس التي تناسب أنواعًا محددة من الاستعلامات، وأقرب هذه الأنواع إلى حالتنا هنا هي فهارس GiST وGIN. والفرق البارز بينهما هو السرعة التي يجلب كل منهما البيانات من الجدول، فـGIN أبطأ أثناء إضافة بيانات جديدة لكنه أسرع في الاستعلام، أما GiST فأسرع في بناء البيانات الجديدة لكنه يحتاج إلى قراءات إضافية للبيانات. وسننشئ فهرس GIN هنا ﻷن GiST أبطأ بثلاث مرات في جلب البيانات: sammy=# CREATE INDEX idx_fts_search ON news USING gin(document); وسيصبح استعلام SELECT أبسط باستخدام عمود document المفهرس: sammy=# SELECT title, content FROM news WHERE document @@ to_tsquery('Travel | Cure'); ويجب أن يكون الخرج شيئًا كهذا: -[ RECORD 1 ]----------------------------------------------------- title | Sleep deprivation curing depression content | Clinicians have long known that there is a strong link between sleep, sunlight and mood. -[ RECORD 2 ]----------------------------------------------------- title | Pacific Northwest high-speed rail line content | Currently there are only a few options for traveling the 140 miles between Seattle and Vancouver and none of them are ideal. واﻵن يمكنك الخروج من لوحة التحكم الخاصة بقاعدة البيانات عبر كتابة q\. الخلاصة يغطي هذا الدليل كيفية استخدام تقنية بحث النصوص الكاملة في PostgreSQL، بما في ذلك تجهيز وتخزين مستند البيانات الوصفية metadata واستخدام فهرس لتحسين أداء البحث. وإن أردت مزيدًا من الشرح حول FTS في PostgreSQL فألق نظرة على التوثيق الرسمي لنظام PostgreSQL حول بحث النصوص الكاملة. ترجمة -بتصرف- لمقال How to Use Full-Text Search in PostgreSQL on Ubuntu 16.04 لصاحبه Ilya Kotov