ما هي خياراتي لتخزين كميات هائلة من البيانات والاستعلام عنها حيث يتكرر الكثير منها؟

Question

أقوم بتقييم الخيارات لتخزين البيانات بكفاءة في Java.مجموعة البيانات عبارة عن قيم بيانات مختومة بالوقت مع مفتاح أساسي مسمى.على سبيل المثال

Name: A|B|C:D
Value: 124
TimeStamp: 01/06/2009 08:24:39,223

يمكن أن يكون سعر السهم في وقت معين، لذلك أفترض أنه نمط بيانات تسلسل زمني كلاسيكي.ومع ذلك، أحتاج حقًا إلى حل RDBMS عام يعمل مع أي قاعدة بيانات معقولة متوافقة مع JDBC حيث أرغب في استخدام Hibernate.وبالتالي، فإن امتدادات السلاسل الزمنية لقواعد البيانات مثل Oracle ليست في الحقيقة خيارًا لأنني أرغب في أن يكون المنفذ قادرًا على استخدام قاعدة بيانات JDBC/Hibernate الخاصة به.

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

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

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

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

لذلك أنا جزء من الاستقالة من نفسي لاحتمال الاضطرار إلى استخدام مخزن بيانات أكثر ملكية [ربما غير SQL] (نقدر أي اقتراحات) ثم التركيز على المهمة الأقل تعقيدًا المتمثلة في كتابة برنامج تشغيل JDBC زائف لتسهيل التكامل على الأقل مع أدوات خارجية.

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

أي اقتراحات أو البصيرة؟

Answer 1

أود أن أنظر إلى أ قاعدة البيانات الموجهة نحو العمود.سيكون أمرا رائعا لهذا النوع من التطبيقات

Answer 2

السبات (أو أي حل JPA) هو الأداة الخاطئة لهذه المهمة.

JPA/Hibernate ليس حلاً خفيف الوزن.في التطبيقات ذات الحجم الكبير، لا تكون النفقات العامة كبيرة فحسب، بل تكون باهظة أيضًا.أنت حقا بحاجة للنظر في حلول الشبكة والكتلة.لن أكرر نظرة عامة على التقنيات المختلفة هنا.

لدي خبرة كبيرة في نظم معلومات الأسواق المالية.بعض ما قلته لفت انتباهي:

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

الآن بالنسبة لحلول نوع الشبكة/العنقودية، أقوم بتقسيمها بشكل فضفاض إلى فئتين:

1. الحلول القائمة على الخرائط مثل Coherence أو Terracotta؛و
2. الحلول المستندة إلى Javaspaces مثل GigaSpaces.

لقد استخدمت التماسك كثيرًا ويمكن أن يكون حل الخريطة لطيفًا ولكنه قد يكون مشكلة أيضًا.يمكن أن تحتوي خرائط التماسك على مستمعين ويمكنك استخدام هذا النوع من الأشياء للقيام بأشياء مثل:

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

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

لقد وجدت أن حلول الشبكة من نوع GigaSpaces أكثر إقناعًا لهذا النوع من التطبيقات.تعد عملية القراءة (أو القراءة المدمرة) حلاً أنيقًا للغاية وقابلاً للتطوير ويمكنك الحصول على تحديثات شبكة المعاملات بأداء أقل من مللي ثانية.

خذ بعين الاعتبار معماريتي الانتظار الكلاسيكيتين:

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

في GigaSpaces، تشبه القراءة المدمرة نظام النشر والاشتراك القابل للتطوير، كما تشبه عملية القراءة نموذج النشر والاشتراك التقليدي.يوجد تطبيق Map و JMS مبني أعلى الشبكة ويمكنه إجراء طلب FIFO.

الآن ماذا عن المثابرة أسمعك تسأل؟المثابرة هي نتيجة لاتخاذ قرار بشأن جميع الأشياء الأخرى.لهذا النوع من التطبيقات، أنا أحب المثابرة كخدمة نموذج (مكتوب بشكل مثير للسخرية عن السبات ولكنه ينطبق على أي شيء).

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

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

إنه موضوع معقد ولم أتطرق إليه إلا حقًا.نأمل أن يساعدك.

Answer 3

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

فيما يلي بعض الروابط الإضافية التي قد تجدها مثيرة للاهتمام:

• LucidDB - متجر عمود مفتوح المصدر
• ان ورقة أكاديمية عن مخازن الأعمدة مقابل مخازن الصف
• شخص اخر التدوين حول صراع مماثل
• SQLStream يستحق المعرفة عنه

Answer 4

العديد من أنظمة إدارة قواعد البيانات التي تدعم JDBC (على سبيل المثال.Oracle) توفر الضغط في محرك التخزين الفعلي.أوراكل، على سبيل المثال، لديها فكرة وجود جدول "مضغوط" بدون حمل إضافي لتخفيف الضغط:

http://www.ardentperf.com/wp-content/uploads/2007/07/advanced-compression-datasheet.pdf

Answer 5

شكرا على الإجابات.

Cletus، أنا أقدر المخطط التفصيلي، ولكن إحدى المقايضات التي لا يمكنني القيام بها هي التخلي عن مرونة قاعدة البيانات والتوافق مع JDBC/Hibernate للسماح باستخدام جميع الأدوات المتاحة.علاوة على ذلك، على الرغم من أنني لم أذكر ذلك بوضوح، إلا أنني لا أريد إجبار المستخدمين على تبني حل تجاري [ربما باهظ الثمن].إذا كان لديهم العلامة التجارية لقاعدة البيانات X، فليستخدموها.إذا لم يهتموا، نوصي بقاعدة بيانات مفتوحة المصدر للعلامة التجارية Y.في الأساس، يحتوي التطبيق على وجوه متعددة، أحدها عبارة عن مستودع للبيانات الواردة، ولكن الوجه الآخر هو مصدر التقارير وأنا حقًا لا ترغب في الدخول في مجال كتابة مولدات التقارير.

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

شكرا على المؤشر، جافامان.لقد قسمتني إلى LucidDB.