تقنيات حلول البيانات هندسة برمجيات يونيو 15, 2024
اختيار قاعدة بيانات مناسبة لمشروعك هو قرار حاسم في عملية تطوير البرمجيات. يعد اختيار قاعدة بيانات ملائمة أساسًا قويًا لإدارة البيانات ويضمن نجاح المشروع على المدى الطويل. في هذا المقال، سنستعرض كيفية اتخاذ القرار الصحيح لاختيار قاعدة بيانات مناسبة.
1. فهم متطلبات مشروعك
قبل أن تبدأ في اختيار و تصميم قاعدة البيانات، من الضروري فهم متطلبات مشروعك حيث لكل مشروع تطوير نظام أو تطبيق خصوصية تختلف عن غيره من الأنظمة. لذا اسأل نفسك الأسئلة التالية:
- ما نوع البيانات التي سيتعامل معها التطبيق أو النظام، فهل هي بيانات مهيكلة Structure Data أو غير مُهيكلة Unstructured؟
- كم حجم البيانات التي تتوقع تخزينها ومعالجتها؟
- ما هي أنماط القراءة والكتابة، فهل هي قراءات متكررة؟
- ما هي توقعاتك حول أداء قاعدة البيانات وقابليتها للتوسع؟
- هل هناك أي متطلبات أمان وامتثال محددة؟ أحيانا تكون متطلبات الالتزام والامتثال التي تفرضها جهة تنظيمة في الدولة أو تفرضها إدارة المخاطر والإلتزام في المنظمة التي تعمل بها مما يلزمك بنوع محدد من أنواع البيانات.
- هل لديك قيود، مثل قيود مالية تتعلق بمحدودية الميزانية؟
الفهم الواضح لاحتياجات مشروعك سيكون بمثابة بوصلة خلال عملية اختيار قاعدة البيانات الأنسب لمشروعك.
2. تحديد نوع قاعدة بيانات والاختيار بين SQL أو NoSQL
يمكن تصنيف أنواع قواعد البيانات بشكل عام إلى نوعين هما SQL وNoSQL، ولكل منها نقاط قوتها وضعفها واستخداماتها وخصوصيتها:
- قواعد بيانات SQL: هي قواعد بيانات علائقية واسمها باللغة الانجليزية هو Relational Database واختصارها هو RDMS. تستخدم قواعد البيانات من هذا النوع لغة تساعدك على التعامل مع قاعدة البيانات، وهي لغة الاستعلامات الهيكلية (SQL) أي Structure Query Language. هذا النوع من قواعد البيانات هو الأنسب للمشاريع التي تتطلب اتساقًا قوي وواضح لشكل وتصميم البيانات، وتتطلب إجراء عمليات معقدة على البيانات المخزنة. من قواعد بيانات SQL الشائعة أذكر لك PostgreSQL, MySQL، وMicrosoft SQL Server. استرجاع البيانات في قاعدة البيانات العلائقية وربط جداولها مع بعضها البعض يعتمد على وجود مفتاح أساسي Primary Key ومفاتيح أخرى ثانوية Foreign Key.
- قواعد بيانات NoSQL: يقدم هذا النوع من قواعد البيانات مرونة أكثر والتي ترفضها وتمنعها قواعد بيانات SQL. قاعدة بيانات NoSQL مناسبة لتخزين البيانات الغير مهيكلة Unstructured وكذلك البيانات الشبه مهيكلة. هي مناسبة للمشاريع التي تتطلب قابلية توسع عالية بحيث تستوعب هياكل مختلفة للبيانات. إذا كان تطبيقك يتطلب عمليات قراءة وكتابة سريعة ومتكررة مثل تطبيقات الشبكات الاجتماعية وتطبيقات طلبات الطعام الي يكون فيها قوائم الطعام مختلفة الهيكلة. أيضاً قواعد بيانات NoSQL لديها القدرة على التعامل مع كميات كبيرة من البيانات وأقرب مثال هي الشبكات الاجتماعية وتطبيقات انترنت الأشياء IoT. من أمثلة قواعد بيانات NoSQL الشائعة MongoDB، Cassandra، وRedis لا ننسى Firebase من شركة جوجل.
| قاعدة بيانات علائقية SQL | قاعدة بيانات غير علائقية No SQL | |
| تُحفظ البيانات في تصميم وهيكل ثابت يُسمة الجدول كل جدول يتكون من حقول لها نوع بيانات محدد | إذا كانت البيانات غير مهيكلة Unstructured data | |
| إذا كان تطبيق مفهوم ACID في قاعدة البيانات مطلوب أترك لك البحث عن المقصود في ACID | إذا كان حجم البيانات المراد تخزينها كبير | |
| إذا كان حجم البيانات التي سيتم حفظها في كل حقل صغير نسبياً | إذا لديك متطلب لعمل تحديثات و lookup | |
| إذا كنت تنفذ استعلامات Query معقدة بين عدة جداول | إذا كان الأداء العالي مطلب وكذلك وقت الاستجابة مطلوب ان يكون منخفض وهو ما يسمة Latency | |
| إذا كان التناسق والتوافق مطلوب بصرامة مع ضرورة توفر أداء يُعتمد عليه |
حتى نكون عمليين ونبتعد قليلاً عن التنظير سوف اعطيك تلميحات تساعدك في كيفية التعرف أكثر على النوع الأنسب. أريد فقط منك أن تركز على مدى تعقيد أنماط الاستعلام التي يتطلبها تطوير النظام. اسأل نفسك الأسئلة التالية:
- ماهي الكيفية التي اريد بها استرجاع البيانات من قاعدة البيانات، إذا كنت ستسترجع البيانات بواسطة رقم تعريفي للسجل يسمى مفتاح السجل، فإن كل ما تحتاجه هو حقل صيغته “مفتاح-قيمة” key-value. هذا النمط من تصميم البيانات يناسبة أكثر قواعد بيانات مثل DynamoDB، Redis، S3 Amazon، GCS.
- أما إذا كنت تسترجع البيانات كثيراً بواسطة مفتاح ولكن أحيانًا تحتاج أيضاً إلى استرجاع البيانات بواسطة حقل أو حقلين آخرين، فقد تكون قواعد البيانات ذات العمود العريض (مثل DynamoDB، Cassandra) هي أكثر ملائمة من قواعد البيانات التي ذكرتها في الفقرة السابقة.
- من ناحية أخرى، إذا كنت ستحتاج إلى الاستعلام بواسطة العديد من الحقول المختلفة، فلا تبتعد عن استخدام قاعدة بيانات علائقية مثل MySQL أو PostgreSQL أو Microsoft SQL الشهيرة, أنا شخصياً لا ابتعد عن هذا النوع من قواعد البيانات قدر الإمكان، ولو اضطررت لاستخدام قاعدة بيانات NoSQL فيكون بشكل جزئي ما أمكنني ذلك.
- أخيرًا، في حال كنت تبحث عن إمكانية البحث في البيانات بأسلوب الاستعلام الغامض أي البحث بكتابة نص حر والذي تعارف المختصون في قواعد البيانات على تسميته Fuzzy query. في هذه الحالة لا تبتعد كثيراً عن محركات البحث مثل Elasticsearch وSolr فهي الأنسب.
3. أسلوب تحديث البيانات المطلوب كمعيار في اختيار قاعدة بيانات
إذا أردت اختيار قاعدة بيانات مناسبة لمشروعك، فمن المهم أن تأخذ في الاعتبار أسلوب تحديث البيانات الذي يحتاجه نظامك. يجب أن تقرر ما إذا كان تمثيل بياناتك سيكون في هيكل جداول SQL أو كوثائق مرنة أو أزواج تتكون من مفتاح وقيمة (NoSQL). إذا كانت بياناتك منظمة للغاية وتتطلب علاقات معقدة، فقد تكون قاعدة البيانات العلائقية هي الاختيار الأمثل. من ناحية أخرى، إذا كانت بياناتك شبه منظمة أو غير منظمة، فقد تكون قاعدة بيانات NoSQL أكثر ملاءمة. هنا يلعب أسلوب تحديث البيانات المطلوب كمعيار مهم في اختيار قاعدة بيانات من نوع SQL أو NoSQL.
دعني أشرح لك أكثر لتتضح الفكرة. إذا كانت طبيعة متطلبات النظام الذي تطوره تتطلب حفظ بيانات وتعديلها في قاعدة البيانات ثم سنحتاج لقراءتها فوراً مع الحصول على آخر تحديث للبيانات دون أي تأخير. ففي هذه الحالة، يُفضل استخدام قواعد البيانات العلائقية (SQL) لأنها مصممة لضمان أن جميع العمليات تتمتع باتساق قوي. نسمي هذه الإمكانية توافق البيانات القوي Strong Consistency. مثل هذا النوع من التحديث ضروري للتطبيقات التي تتطلب تحديث وتوافق فوري ولحظي للبيانات، مثل تطبيقات البورصة أو أنظمة الحجز. قواعد البيانات التي تتوفر فيها القدرة على التوافق القوي ستضمن لنا دقة البيانات وعدم وجود تأخير في التحديثات. من أمثلتها نذكر MySQL, PostgreSQL, Microsoft SQL Server, Oracle Database.
على النقيض، بعض الأنظمة لا تحتاج لميزة توافق البيانات القوي Strong Consistency وتقبل أن يكون هناك تحديث تدريجي للبيانات. فإذا كانت متطلبات النظام الذي تطوره لا تلزمك بالتحديث الفوري، وتسمح لك كمصمم للنظام بأن يتأخر تحديث سجلات قاعدة البيانات ولكن في نهاية المطاف مطلوب الحصول على تحديث نهائي ودقيق للسجلات في قاعدة البيانات، فهذا نسميه توافق مؤجل للبيانات Eventual Consistency. هذا الأسلوب يضمن أن جميع النسخ من البيانات ستصل إلى نفس الحالة في النهاية، لكن قد يكون هناك بعض التأخير قبل أن تكون جميع النسخ محدثة. هذا النوع من التحديث مناسب للتطبيقات التي يمكنها تحمل تأخير قصير في تحديث البيانات، مثل الشبكات الاجتماعية أو أنظمة تخزين الملفات، حيث الأولوية تكون لأداء النظام والتوسع على حساب التحديث الفوري.
فيما يلي أمثلة على قواعد البيانات التي تدعم الاتساق المؤجل (Eventual Consistency):
- Cassandra: قاعدة بيانات NoSQL موزعة تعتمد على هيكل الأعمدة العريضة (Wide-Column Store)، وتستخدم بشكل شائع في التطبيقات التي تحتاج إلى كتابة بيانات بسرعة وتحتمل تأخيراً في الاتساق.
- DynamoDB: خدمة قاعدة بيانات NoSQL تقدمها أمازون AWS، وهي مصممة لتوفير أداء عالٍ وقابلية توسع كبيرة مع دعم الاتساق المؤجل.
- MongoDB: قاعدة بيانات NoSQL موجهة للمستندات، والتي يمكن إعدادها للعمل في وضع الاتساق المؤجل لتلبية احتياجات التطبيقات التي تحتاج إلى مرونة في هيكل البيانات وأداء عالي في الكتابة.
- Riak: قاعدة بيانات NoSQL تستخدم نموذج القيمة المفتاحية (Key-Value Store)، وتوفر مستوى عالٍ من التوفر والقدرة على التوسع مع دعم الاتساق المؤجل.
- CouchDB: قاعدة بيانات NoSQL تستخدم نموذج المستندات، وتدعم الاتساق المؤجل مع إمكانية التكرار التلقائي وتوزيع البيانات عبر عقد متعددة.
هذه القواعد تتميز بقدرتها على توفير أداء عالٍ وقابلية توسع كبيرة، وهي مناسبة للتطبيقات التي يمكنها تحمل تأخير مؤقت في اتساق البيانات.
4. متطلبات التوسع
من المهم معرفة متطلبات التوسع لمشروعك قبل اختيار قاعدة البيانات. إذا كنت تتوقع نمواً سريعاً وعدد مستخدمين عالي، فقد تحتاج إلى قاعدة بيانات يمكن توسيعها أفقياً وذلك يتم بإضافة مزيد من الخوادم لتوزيع القدرة الاستيعابية. قواعد بيانات NoSQL غالبًا ما تكون مفضلة لقدرتها على التوسع بسهولة. مما لا شك فيه أنه توسيع قواعد بيانات SQL ولكن هذا يتطلب تخطيطاً وجهدًا أكبر. أحد أهم اسباب المرونة في قواعد بيانات NoSQL أنها قابلة للتوزيع وتقبل توزيع الأحمال الناتجة من كثرة العمليات التي تؤثر على قاعد البيانات بسبب توايد عدد المستخدمين أو تزايد عمليات الشراء على متجر إلكتروني وغيره من الأسباب.
5. الأداء
الأداء هو جانب حيوي لأي قاعدة بيانات. اعتمادًا على حالة استخدام تطبيقك، قد تحتاج إلى سرعات قراءة أو كتابة سريعة، أو كمون Latency منخفض، أو القدرة على التعامل مع اتصالات متزامنة. قم بإجراء اختبارات الأداء والمقارنات لتحديد أي قاعدة بيانات يمكنها تلبية متطلبات أدائك. أحد الأمور التي تساعدك على معرفة الأداء المطلوب هو أن تعرف كيف تقدر معدل الإنتاجية (Throughput) والكمون (Latency) المطلوبين ولكن ماهو المقصود فيهما.
- الكمون Latency هو الوقت الذي يستغرقه النظام للاستجابة لطلب معين، مثل تنفيذ استعلام أو عملية قراءة أو كتابة. كلما كان Latency منخفضًا، كان أداء النظام أفضل واستجاب بسرعة أكبر.
- الإنتاجية Throughput هي كمية العمليات (مثل القرأة أو الكتابة في قاعدة البيانات والتي يمكن للنظام معالجتها في فترة زمنية معينة، ويتم حساب Throughput بعدد العمليات التي يمكن للنظام تنفيذها في الثانية.
كل قواعد البيانات تتدهور في الأداء مع زيادة حركة المرور أي تزايد في عدد المستخدمين ومرات الاستخدام مما ينتج عنه تزايد مرات القراءة والكتابة (Read/Write Traffic). في هذا الوقت، تكون التحسينات مثل إعادة الفهرسة (Re-indexing) وإعادة تقسيم البيانات (Re-sharding) داخل قاعدة البيانات مفيدة. في حال كنت تواجه حركة مرور عالية جدًا وتحتاج إلى كمون منخفض جدًا، فإن حلول مقدمي خدمات الحوسبة السحابية مثل DynamoDB من أمازون وBigtable من جوجل سيوفرون لك ما تحتاجه وبالطبع كل شيء له تكلفته.
6. التوافر والموثوقية
وقت التوقف عن العمل يمكن أن يكون مضرًا لمشروعك. ضع في اعتبارك توفر وموثوقية قاعدة البيانات. هل تدعم ميزات التوافر العالي مثل النسخ الاحتياطي، والتحول التلقائي، وحلول النسخ الاحتياطي؟ تأكد من أن قاعدة البيانات التي تختارها يمكن أن تلبي متطلبات الجاهزية لمشروعك.
7. الأمان والامتثال
إذا كان مشروعك يتعامل مع بيانات حساسة أو تقع تحت إشراف تنظيمي معين مثل هيئات الرقابة الحكومية الخاصة بالبيانات وأمن المعلومات، فإن الأمان والامتثال هما أمران أساسيان. تحقق مما إذا كانت قاعدة البيانات توفر التشفير، والتحكم في الوصول، وميزات التدقيق التي تتماشى مع متطلبات الأمان ومعايير الامتثال المطلوبة منك.
8. التكامل مع الأنظمة الأخرى
يجب أن تكون قاعدة البيانات قادرة على التكامل والربط مع الأدوات والخدمات الأخرى في مشروعك. على سبيل المثال، إذا كان مشروعك يتطلب توفير خاصية تحليلات لبيانات ضخمة باستخدام Apache Spark، فعندها يجب أن تستخدم قاعدة بيانات تتكامل وترتبط بسهولة مع Spark. كذلك، إذا كنت تنقل من قاعدة بيانات أحادية إلى قاعدة بيانات غير علائقية، تأكد من أن قاعدة البيانات الجديدة توفر واجهة SQL إذا كانت تطبيقاتك تعتمد عليها. هذا يتطلب منك التركيز على توفر API و Data Adapter لتسهيل الاتصال والربط كع قواعد البيانات مثل ODBC أو JDBC وغيرها.
9. ضع CAP في اعتبارك
يجب أن تفهم مفهوم CAP لتختار قاعدة البيانات الأنسب لمتطلباتك. CAP هو اختصار لثلاثة كلمات وكل كلمة هي تمثل خاصية من خصائص قواعد البيانات. أولها الاتساق Consistency ثم التوافر Availability وثالثها خاصية “إمكانية تحمل التقسيم” Partition Tolerance. لا يمكن تحقيق جميع هذه الخصائص بأفضل شكل في قاعدة بيانات واحدة، لذا عليك تحديد أولوياتك حسب متطلبات مشروعك واختر خاصيتين على الأكثر ويجب أن تتوفر في قاعدة البيانات التي تختارها من أصل ثلاثة خصائص:
- الاتساق Consistency: شرحتها في فقرة سابقة وهي أنه عند استرجاع بيانات من قاعدة البيانات فيجب أن تُعيد لي أحدث نسخة من البينات المُخزنة. هذه الميزة توفرها قواعد البيانات العلائقية.
- التوافر Availability : النظام يستجيب حتى في حالة فشل بعض الخوادم.
- تحمل التقسيم Partition Tolerance: النظام يواصل العمل حتى في حالة فشل الشبكة أو الخوادم.
نظرية CAP تنص على أنك لا تستطيع تحقيق جميع هذه الخصائص بأفضل مستوى في قاعدة بيانات واحدة، لذا عليك اختيار اثنين فقط من الثلاثة في وقت واحد، وهذا يعتمد على أولوياتك التي يُحددها متطلبات مشروعك. على سبيل المثال، إذا كان نظامك يحتاج إلى التوافر وإمكانية تحمل التقسيم، فعليك أن تكون مستعدًا لقبول بعض التأخير في متطلبات الاتساق. الصورة أدناه توضح مثلث التوازن بين ثلاثة الخصائص وبناء على الخاصيتين التي تختارها من المثلث سوف يتضح لك اي نوع قاعدة بيانات يُناسب مشروعك والنظام الذي تطوره.
لمزيد من التوضيح، فإن قاعدة البيانات العلائقية التقليدية (SQL) تتناسب بشكل طبيعي مع جانب الاتساق والتوافر (CA)، بينما محركات قاعدة البيانات غير العلائقية (NoSQL) تلبي غالبًا متطلبات التوافر وتحمل التقسيم (AP) أو الاتساق وتحمل التقسيم (CP).
الاتساق الذي شرحته من قبل يعني أن أي استرجاع للبيانات من قاعدة البينات فأتوقع أن يعيد لي أحدث بيانات محفوظة في قاعدة البيانات. عادةً ما يكون الاتساق قويًا في قواعد البيانات العلائقية (SQL)، بينما في قواعد البيانات غير العلائقية (NoSQL) يمكن أن يكون الاتساق بين القوي والمؤجل.
بالنسبة للتوافر فهو يعني أن العقدة node في الشبكة والغير مستجيبة يجب أن تستجيب في وقت معقول. ليس كل تطبيق يحتاج إلى العمل 24/7 بنسبة توافر 99.999%، ولكن من المحتمل أنك ستفضل قاعدة بيانات تقدم لك توافر أعلى. أما تحمل التقسيم Partition Tolerance فيعني أن النظام سيستمر في العمل رغم فشل الشبكة أو العقد.
إن نوع التطبيق أو النظام الذي تطوره سيحدد نوع قاعدة البيانات والخصائص التي تريد توفرها فيها، وأنت الوحيد الذي يعرف المتطلبات الفعلية. اسأل نفسك هل مشروعك يقبل أن يتعطل نظامك لبضع ثوانٍ أو دقائق؟ إذا لم يكن كذلك، فيجب أن يكون التوافر هو همك الرئيسي. أما إذا كنت تتعامل مع بيانات تتطلب إنجاز عمليات في الوقت الفعلي الحقيقي Real-Time مثل تطبيق تداول الأسهم، فحتماً أنت ستحتاج إلى خاصية الاتساق قبل اي شيء آخر. حتى لو قررت فحاول اختيار قاعدة البيانات التي تناسب التنازلات التي قررت الأخذ بها.
10. نماذج البيانات (Schemas)
من طبيعة قواعد البيانات العلائقية SQL أنها تخزن البيانات في جداول ذات تصميم هيكلي ثابت ومعرف من قبل مصمم قواعد البيانات، مما يعني أنه يجب عليك تحديد نموذج البيانات حسب متطلبات نظامك ويمكن أن تغير تصميم الجداول (إضافة حقول) وتغيير العلاقات بينها كلما تغيرت متطلبات النظام. أما قواعد بيانات NoSQL فهي أكثر مرونة ولا تتطلب تحديد النموذج مسبقًا، مما يجعلها أكثر ملاءمة للتطوير السريع والتغييرات المستمرة.
أيضاً، لا تضع قواعد بيانات NoSQL قيوداً على أنواع البيانات التي يمكنك تخزينها. فهي تسمح لك بإضافة أنواع جديدة من البيانات مع تغير احتياجاتك. في عملية بناء التطبيقات، يفضل معظم المطورين البدء بكتابة كود البرمجة بسرعة وأن يحصلوا من قواعد البيانات على مرونة الكبيرة بدون قيود. وقد أثبتت قواعد بيانات NoSQL أنها خيار أفضل بكثير في هذا الصدد، خاصة للتطوير بمنهجية التطوير المرن والسريع والذي يُسمى Agile Development.
11. التكلفة والترخيص
تأتي قواعد البيانات مع مجموعة متنوعة من نماذج الترخيص والتكاليف. بعض قواعد البيانات مفتوحة المصدر ومجانية، بينما يتطلب البعض الآخر رسوم ترخيص. ضع في اعتبارك ميزانية مشروعك وفكر في التكلفة الكلية للملكية، بما في ذلك الأجهزة، والصيانة، والدعم. إذا اخترت حلاً سحابياً مداراً، فيجب عليك أن تعرف ما هي التكاليف؟ وما هي حدود الإمكانيات المتاحة حسب السعر؟
النموذج المالي للحلول السحابية المُدارة عادة ما يكون متناسباً مع حركة المرور للقراءة/الكتابة. تأكد من قراءة التفاصيل الدقيقة لكل حل مُدار وتأكد من أنه فعال من حيث التكلفة لأنماط الاستخدام الخاصة بك للقراءة/الكتابة. ضع في اعتبارك أن التكاليف يمكن أن تتراكم بسرعة، خاصة إذا كان مشروعك يتطلب قراءة وكتابة مكثفة للبيانات. لذا، يجب أن توازن بين التكلفة والفوائد التي ستحصل عليها من استخدام قاعدة بيانات معينة، وضمان أن تكون التكلفة الكلية للملكية مناسبة لميزانية مشروعك. للتعرف على سبل إدارة ميزانية الخدمة السحابية للنظام الذي نشرته، أدعوك لقراءة مقال “تعرف على FinOps لتحسين الكفاءة المالية والتقنية مع الحوسبة السحابية”.
.
12. النضج والاستقرار
إذا اخترت استضافة نظامك وقاعدة البيانات الخاصة به في خادم خاص بك في مركز البيانات الذي تُديره جهة عملك، ففكر في مدى النضج التقني وخبرة فريقك التشغيل لديكم. قد يكون من المغري اختيار قاعدة بيانات أحدث وأكثر قوة، ولكن إذا لم يكن لدى فريق التشغيل خبرة بها، فقد تندم على ذلك. في بعض الأحيان، يكون اختيار قاعدة بيانات مجربة ومختبرة داخل جهة عملك هو أكثر فائدة على المدى الطويل.
لا تتغافل عن أن إعداد وتكوين وضبط قواعد البيانات عملية طويلة ومحفوفة بالمخاطر. في بعض الأحيان، اختيار قاعدة بيانات تقليدية والتي تعتمد عليها جهة عملك منذ فترة طويلة قد يؤدي إلى تحقيق فوائد أكبر على المدى الطويل عندما يتعلق الأمر باستقرار بيئة الإنتاج Production Environment.
الخلاصة
اختيار قاعدة بيانات المناسبة لمشروعك هو قرار كبير يتطلب دراسة متأنية لاحتياجات مشروعك الخاصة والقيود. خذ وقتك في تقييم الخيارات، وإجراء الاختبارات، والنظر في التوسع، والأداء، والأمان، والتكامل مع الأنظمة الأخرى. الحفاظ على البساطة هو المفتاح، لذا تجنب التعقيد غير الضروري واختر التقنية التي تلبي احتياجاتك بأقل قدر من التعقيد. القرار الصحيح سيؤسس أساساً قويًا لإدارة بيانات مشروعك ويضمن نجاحه على المدى الطويل.
