پایگاه داده برای 1 میلیون کاربر و 5 میلیون رکورد

[milad_d993]

سلام دوستان
آیا mongoDB برای این منظور خوبه؟؟؟؟
سوال دومم هم درمورد سرعت جستجو توی این بانک اطلاعاتی هست؛ به من گفتن که هرگونه index گذاری توی RDBMS ها با این حجم اطلاعات منجر به کاهش سرعت میشه

برای من سرعت جستجو و درج اطلاعات خیلی مهمه...

توی noSQL و بخوصص mongoDB باز هم index گذاری داریم؟؟؟ و یا امکان استفاده از موتور های جستجو نظیر Sphinx هست؟؟؟

برای جستجو در مختصات جغرافیایی (lat & lng) که در بانک ذخیره شده مناسبه؟؟؟

[cups_of_java]

اعداد شما اندازه ای نیستن که مانگو دی بی در هندل کردن اونا به مشکل بخوره.

مانگو امکان جستجو و ایندکس گذاری جغرافیای هم داره بله.

[terminator68]

از بانک دیتابیس اوراکل استفاده کن...
سرعتش عالیه تو درج و جست و جو...

[ahmad.t1100]

از اوراکل چرا استفاده کنه؟؟؟مانگو دی به این خوبی.درضمن 1 میلیون کاربر و 5 میلیون رکورد چیزی نیست که بخواد توی جستجو یه دیتابیس رو اذیت کنه شما با اماتوری ترین الگوریتمم جستجوی خودتون رو بنویسید مشکلی واستون پیش نمیاد

[-سیّد-]

اول از همه بگم که این جمله اصلاً درست نیست:


هرگونه index گذاری توی RDBMS ها با این حجم اطلاعات منجر به کاهش سرعت میشه

ما بیش از ۲۰۰ میلیون رکورد رو توی MySql ذخیره کردیم و روش هم index داریم، زیر ۱۰ میلی‌ثانیه جواب می‌گیریم. تازه اون هم توی موتور جستجو، نه یه نرم‌افزار معمولی (البته برای جستجوی query کاربر قطعاً از MySql استفاده نمی‌کنیم، چون شدنی نیست. index کلاً ماجراش فرق می‌کنه. ولی برای بخش‌های دیگه‌ای از MySql استفاده می‌کنیم).
در ضمن ما به صورت stream داریم داده‌ها رو update می‌کنیم.

البته ما از هارد SSD استفاده کردیم، ولی اگه هاردتون SATA هم باشه، سرعت خیلی پایین نیست.

اینجا ۲ تا نکته‌ی بسیار مهم وجود داره.
یکی این که شما چه ستون‌هایی رو می‌خواین index کنین و چه query هایی می‌خواین بزنید؟ اگه فقط یه ستون عددی رو index می‌کنید و query تون هم فقط یه lookup ساده هست (یعنی یه SELECT با یه WHERE روی اون ستون، که فقط یک یا چند رکورد رو برمی‌گردونه)، هیچ مشکلی نخواهید داشت. اما اگه تعداد ستون‌هایی که index می‌کنید بیشتره، یا نوعشون عددی نیست، یا query تون پیچیده‌تر هست (مثلاً توش قراره join داشته باشید)، ماجرا فرق می‌کنه.

نکته‌ی دوم این که نحوه‌ی طراحی پایگاه داده خیلی توی سرعتش تأثیر داره. ما ۳-۴ بار طراحیمون رو عوض کردیم تا به اینی که گفتم رسیدیم. نوع engine، نوع index، نوع row format، استفاده از partitioning، و ... همگی تأثیر دارن.


من این رو همیشه می‌گم: تا وقتی که یه RDBMS جواب کار شما رو می‌ده، سراغ روش‌های NoSQL نیاین، چون overhead یادگیری و administration شون به شدت بیشتر از سیستم‌های RDBMS هست (مخصوصاً چون توزیع‌شده هستن). ولی نکته‌ای که هست اینه که تغییر روش از SQL به NoSQL، برای شما هزینه خواهد داشت. برای همین، اول کار نیاز آینده‌تون رو بسنجید. مثلاً ببینید که ۵ سال دیگه، ۱۰ سال دیگه، چقدر داده و کاربر خواهید داشت؟ آيا همون RDBMS جواب اون موقع رو هم می‌ده یا نه؟ اگه نه، ممکنه براتون بصرفه که از همین الان روی NoSQL سرمایه‌گذاری کنید.

[milad_d993]

با تشکر از همه دوستان

ببینید حداقل بر اساس 3 فیلد lat,lng و فیلد username باید index گذاری کنم؛

توی یک کوئری دیگه شرط فقط username هست....

و توی یک کوئری شرط اصلی فقط lat و lng هستش

سوالی که الان ذهنم رو مشغول میکنه اینه که اگر به فرض ما همه (اکثر) فیلد ها رو index کنیم اما توی هر کوئری فقط بر اساس یکی از فیلد ها اطلاعات رو بکشیم بیرون مشکلی به وجود نمیاد؟؟؟ بعد روی سطر های واکشی شده یه کوئری دیگه بزنیم....؟؟؟؟؟؟؟؟؟

یکی از دلایلی هم که نمیخوام از mysql استفاده کنم اینه که ممکنه کاربر یه سری از فیلد ها رو که اختیاری هستند خالی بزاره و بجاش یه سری فیلد اختیاری دیگه رو پرکنه.....

[-سیّد-]

برای این وضعیتی که می‌گید (۲ تا فیلد عددی و یک فیلد varchar) نمی‌دونم، باید آزمایش کنید که روی تعداد رکوردی که گفتید (و همونطور که گفتم در آینده (مثلاً ۵ سال دیگه) بهش می‌رسید) با این وضعیت، سرعتتون چطور خواهد بود. دوستان دیگه اگه تجربه‌ای دارن در اختیار بذارن.

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

در مورد مسئله‌ی آخری که گفتید، به این بستگی داره که چند تا فیلد اینجوری دارید. اگه مثلاً ۲-۳ تا فیلد هستن که ممکنه خالی بمونن، می‌تونین مقدار null براشون بذارین و لزومی به استفاده از Key-Value store برای این کار ندارین. ولی اگه تعداد فیلدهای اختیاری زیاد هستن (مثلاً ۱۰-۲۰ تا، یا به صورت نامتناهی)، اون وقت باید به سراغ یه Key-Value store برین. البته باز برای این حالت هم می‌شه روش‌های دیگه‌ای استفاده کرد (مثلاً این که از یه engine خود MySQL استفاده کنین که بر مبنای Key-Value هست، یا این که داده‌تون رو به یه فرمتی (مثل json یا protobuf) تبدیل کنید و کلاً یه فیلد توی پایگاه داده داشته باشید که اون داده رو توش ذخیره می‌کنید).

برای چی اینو می‌گم؟ به خاطر همون حرفی که توی پست قبل زدم:


تا وقتی که یه RDBMS جواب کار شما رو می‌ده، سراغ روش‌های NoSQL نیاین، چون overhead یادگیری و administration شون به شدت بیشتر از سیستم‌های RDBMS هست (مخصوصاً چون توزیع‌شده هستن).


یه دلیل دیگه هم اینه که توی query زدن، هیچ کدوم از این سیستم‌های NoSQL و توزیع شده، به گرد پای RDBMS های معمولی نمی‌رسن. یعنی یه سرور MongoDB یا HBase یا Cassandra یا هر کدوم دیگه از این سیستم‌ها، سرعتش شاید در حد یک دهم سرعت یه سرور MySQL یا MSSQL یا Oracle یا PostgreSQL یا امثالهم باشه. مزیت اصلی اون سیستم‌ها چیزهای دیگه‌ایه (مثل مقیاس‌پذیری تقریباً بینهایت، یا fault-tolerant بودنشون، یا Key-Value بودنشون...). اصلاً به خاطر همین هم هست که ما بعضی از جاهای موتور به جای این سیستم‌ها از MySQL استفاده می‌کنیم. صد البته بعضی جاهای دیگه هم داریم از همین سیستم‌های توزیع شده استفاده می‌کنیم، هر کدوم سر جاش و برای کاربرد خودش (دقت کنید که مقیاس کار یه موتور جستجو مثل یوز، به مراتب فراتر از مقیاس اکثر پروژه‌های دیگه‌ی کشور هست: میلیاردها صفحه باید به صورت stream و realtime بیاد و index بشه و جواب هزاران جستجوی کاربران رو در کمتر از یک ثانیه توی خروجی بده. برای همین می‌گم که کاملاً ممکنه بتونید با یه RDBMS کارتون رو انجام بدید).