انتخاب پایگاه داده مناسب برای هوش مصنوعی [بایگانی]

aliagamon

شنبه 30 خرداد 1394, 23:33 عصر

سلام
من روی یک برنامه کار میکنم که به دلیل نوغ ساختارش در بخشی از کار نیاز به یک پایگاه داده انعطاف پذیر داره راستش من تا حالا با دیتابیس های nosql کار نکردم چیزی که من نیاز دارم دیتابیسی هست که N شی رو به M شی ربط بده
راستش واسه یه هوش مصنوعی نیاز دارم که حجم زیادی داده رو با یه برنامه دیگه پردازش و انتخاب کنم (از بستر نت مثلا نوینر) و به دیتابیش اصلی برنامه بدم که اون بعد از انجام NLP روی ورودی از پایگاه برای پیداکردن جواب استفاده کنه
مثلا این عکس رو ببینین
132451
میخوام با حستحو برای key 1 به مجموعه تمام M مقدار گروه value دست پیدا کنم حالا با حستحوی key 2 تا key N هم به همین نتیحه برسم این بخش اول کار هست
یه سوال دیگه هم دارم که ممکنه فعلا استفاده نشه اما میخوام پایگاه داده مناسبش رو پیدا کنم که خواستم به این فرم پایگاه انتقال بدم سیستمو مجبور به تعویض پایگاه نشم میخوام که مجموعه value ها نیز خود زیرمجموعه خودشونو داشته باشن به عکس زیر توجه کنین
132452
اینجا اگه هر سیلندر رو یک مجموعه درنطر بگیرین (مثل مجموعه ی key ها) میخوام با جستجوی یک عضو A به مجموعه ی B و C دسترسی پیدا کنیم و با جستوجوی عضو های B به C برسیم و به همین ترتیب با جستجو ی C به D این مورد جهت بهینه کردن پایگاه و کمتر کردن حجم بعدا نیاز میشه و ممکنه گروه ها همپوشانی داشته باشند
حالا بنظر شما بهتری دیتابیس برای این کار چیه ؟ فاکتور سرعت جستجو هم درنظر بگیرین ممکنه حجم پایگاه بعد از چند سال ده ها گیگ بشه

-سیّد-

دوشنبه 01 تیر 1394, 02:36 صبح

من نمی‌تونم جواب کاملی به شما بدم. ولی چند تا نکته به نظرم می‌رسه.
اول این که تا وقتی که پایگاه‌های داده‌ی رابطه‌ای مشکل شما رو حل می‌کنن، خییییییییییییلی به نفعتونه که به سمت پایگاه‌های داده‌ی غیر رابطه‌ای نرین، چون یه لایه پیچیدگی اضافه می‌شه. نکته‌ی مهمی که توی پایگاه‌های داده‌ی NoSql وجود داره اینه که معمولاً به خوبی scale می‌شن. اگه تا اطلاع ثانوی (یعنی مثلاً تا ۵ سال دیگه) از نظر حجم داده به مشکلی برنخواهید خورد، توصیه‌ی اکید می‌کنم که سمت NoSql نیاین.

فاکتور سرعت جستجو هم درنظر بگیرین ممکنه حجم پایگاه بعد از چند سال ده ها گیگ بشه
دهها گیگ برای پایگاه‌های داده‌ای مثل MySql هیچی نیست. ما توی موتور یوز، چند صد گیگابایتی از MySql استفاده می‌کنیم و به خوبی داریم جواب می‌گیریم (یعنی در حد چند میلی‌ثانیه به ما جواب می‌ده). از نظر تعداد رکوردها هم به راحتی صدها میلیون رکورد رو جواب می‌ده. تازه اینو در نظر بگیرید که معمولاً این جور کارا به صورت batch انجام می‌شه، در حالی که ما به صورت realtime داریم از MySql استفاده می‌کنیم (یعنی داده‌های جدید به محض ورود به سیستم وارد پایگاه‌های داده می‌شن). البته این رو هم بگم که ما توی بخش‌های مختلف موتور هم از پایگاه‌های داده‌ی رابطه‌ای استفاده می‌کنیم، هم از پایگاه‌های داده‌ی غیر رابطه‌ای. به عنوان مثال، index رو توی پایگاه داده‌ی رابطه‌ای ذخیره نمی‌کنیم، چون مقیاس خیلی بالا هست و باید scalable باشه.

اینجوری که گفتید، فکر می‌کنم می‌تونید یه جدول برای key ها تعریف کنید، یه جدول هم برای خود value ها. بعد یه جدول برای گروه‌های value، یه جدول هم برای ارتباط بین key ها و گروه‌های value. یعنی همون مثال اولی که زدید اینطوری می‌شه:
key

name
id

Key1
1

Key2
2

Key3
3

Key4
4

Key5
5

value

value
id

Value1
1

Value2
2

Value3
3

Value4
4

Value5
5

value_group

value_id
group_id

1
1

2
1

3
1

4
1

5
1

key_value_group

value_group_id
key_id

1
1

1
2

1
3

1
4

1
5

البته من این جداول رو خیلی سریع طراحی کردم، شاید بشه بهتر هم طراحی کرد (بستگی به کاربرد دقیقتون هم داره، مثلاً شاید بتونید اون جدول کلید رو کلاً حذف کنید و مستقیماً خود کلیدها رو توی جدول آخر استفاده کنید).

در نهایت هم بگم که همه‌ی اینها به یه سری پارامتر وابسته هست: نحوه‌ی طراحی جداول (و در نتیجه query ها)، نحوه‌ی انتخاب engine ها و index ها، سخت‌افزار مورد استفاده (مثلاً اگه از هارد دیسک SSD استفاده کنید، سرعت خوندن داده به مراتب سریعتر می‌شه، یا این که حتماً به اندازه‌ی کافی RAM به سیستم بدید که cache اش به خوبی استفاده بشه) و ...
در نتیجه حتماً توصیه می‌کنم یه بار روی یه پایگاه داده‌ی رابطه‌ای آزمایش کنید. یعنی اون حد بالایی که فکر می‌کنید (مثلاً ۳۰ گیگ) رو شبیه‌سازی کنید و توی پایگاه داده بریزید و روش تست کنید. اگه سرعتتون افتضاح شد، اون وقت باید یه فکر دیگه بکنید (باز ممکنه بتونید optimize کنید و سرعت رو چندین برابر کنید، یا ممکنه بعد از انجام تمام optimization ها به این نتیجه برسید که به سراغ پایگاه‌های داده‌ی NoSql بیاید).

این رو هم در نظر داشته باشید: قطعاً سرعت پاسخگویی پایگاه‌های داده‌ی NoSql به مراتب کمتر از سرعت پایگاه‌های داده‌ی رابطه‌ای هست (در صورتی که یک سرور رابطه‌ای رو با یک سرور غیر رابطه‌ای مقایسه کنیم). یعنی اگه روی یه سرور MySql بذارید، روش یه تعداد مشخصی داده بریزید، روش تست بزنید، بعد روی همون یک سرور یه پایگاه داده‌ی NoSql بذارید، و روش همون داده‌ها رو بریزید و تست کنید، شاید تا دهها برابر کندتر جواب بگیرید. پس پایگاه‌های داده‌ی NoSql به چه درد می‌خورن؟ اولیش اینه که بعضی جاها اصلاً نمی‌تونید با پایگاه‌های داده‌ی رابطه‌ای داده‌تون رو مدل کنید. اون جاهایی که می‌تونید این کار رو بکنید چی؟ نکته‌ی مهمشون توی اینه که می‌تونید برای یه پایگاه داده‌ی NoSql از مثلاً ۲۰ تا سرور با مشخصات معمولی استفاده کنید، به جای این که یه سرور خفن بذارین برای MySql که قیمتش ۱۰۰ برابر اونا در بیاد! و این که می‌تونید با ۵ تا سرور شروع کنید، در اثر مرور زمان که داده زیاد شد، تعداد رو افزایش بدید (چیزی که توی پایگاه‌های داده‌ی رابطه‌ای به راحتی قابل انجام نیست). و همچنین این که به شما قابلیت تحمل‌پذیری خطا رو می‌دن، یعنی اگه یه سرور بترکه، اتفاقی برای کل سیستم نمی‌افته، در حالی که اگه اون یه دونه سرور خفن MySql تون بپکه، همه چیز از دست می‌ره! پس باید بکنیدش ۲ تا! در نتیجه هزینه ۲ برابر می‌شه!