ویدیویی که لینک‌ش در انتها ذکر شده، نکات آموزنده و واقع‌بینانه‌ای در مورد انتخاب درست یک دیتابیس برای یک کسب و کار در حال رشد رو عنوان میکنه.
صحبت در مورد بیزینسی هست که به شدت در حال رشد هست و حجم داده رشد سریعی داره
قدم اول اینه که با دقت سعی کنیم مستندات دیتابیس فعلی رو بخونیم و از متخصصین کمک بگیریم که بتونیم دیتابیس فعلی رو با tune کردن و استفاده از تغییرات کانفیگ بهینه کنیم که بتونیم مدیریت کنیم رشد سریع داده هارو
اگه به هر دلیلی دیتابیس فعلی مناسب نبود باید در قدم اول چشمامونو باز کنیم و حتما محدودیت های کاندیداهای جایگزین رو خوب بخونیم (خیلی از دیتابیس ها شعارهای خلاف واقع میدن و محدودیت هایی دارن که در مستنداتشون فقط میشه بهشون رسید…)
قبل از اینکه بخوایم عملیات انتقال داده به دیتابیس جدید رو انجام بدیم، باید بین کاندیداهای نهایی با انجام بنچمارک های خوب و قوی و چک کردن همه معیارها مثل p99 و غیره سعی کنیم گزینه مناسب تر رو انتخاب کنیم. (این بنچمارک باید روی داده واقعی خودمون انجام بشه و با کوئری های واقعی بیزینس انجام بشه)
در نهایت باید عملیات انتقال رو برنامه ریزی کنیم و با حوصله و طبق برنامه کار انتقال رو انجام بدیم
در ابتدا ما مطمئن باشیم که به یک پایگاه داده متفاوت «نیاز» داریم.
آیا دلیل کافی برای اینکه یک Alternative داشته باشیم، هست؟
آیا پایگاه‌داده فعلی در «درز(ها)/حفره‌ها»، شکننده هست؟
شاید وضعیت فعلی، حاصل تنظیم «مقدار مموری در دسترس»، روی حداکثر آن هست.
یا حتی شاید بیشتر درخواست‌های ابتدایی، نیاز به خواندن «از روی دیسک» دارند، و همه‌چیز رو کُند می‌کنند.
موضوع(ها)، هرچه باشند، مطمئن شوید که براحتی قابل حل نیستند. (دلیل کافی برای تغییر وجود داشته باشد)
ابتدا بریم مستندات پایگاه داده فعلی رو مطالعه کنیم. از ظاهر تا باطن‌ش رو دوباره بخونیم.
می‌تونه یکی دو تا ابزار برای تنظیمات وجود داشته باشه، که استفاده کنیم و کمی اوضاع بهتر بشه.
این موقعیت می‌تونه مفید باشه، چون تغییر پایگاه داده می‌تونه مدت‌ها طول بکشه، معمولاً خیلی بیشتر از چیزی که فکرشو کنیم …
این ابزارها (config):
– می‌تونه تنظیم میزان اندازه حافظه در زمان اجرا باشه …
– می‌تونه انتخاب سناریو‌های دیگر برای فشرده سازی باشه …
−− می‌تونه حتی تغییر رفتار GC باشه …
پایگاه‌های داده، پیچیده هستند و با پتانسیل «تنظیم‌پذیری» بالا، معماری‌شون رو درک کنیم و درباره «محدودیت»هاشون بیشتر بدونیم.
یه سری به جامعه تخصصی بزنیم، درباره مشکلات گفتگو کنیم، معمولاً دیگر متخصصین، می‌تونن کمک کنند و اغلب راه‌حل‌های غافل‌گیرانه‌ای هم ارائه می‌کنند، با جستجوی بیشتر روی منابع دیده‌نشده شاید به راه‌حل‌هایی متناسب با معماری نرم‌افزارمان برسیم…
آیا می‌تونیم یک سیستم cache سرراه‌ش بذاریم که بهمون باند بیشتری بده؟
آیا می‌تونیم یک سیستم توزیع و خواندن برای کمک به تخلیه (اطلاعات) در زمان خواندن، اضافه کنیم؟
آیا می‌تونیم پایگاه داده رو به قسمت‌هایی کوچکتر تقسیم کنیم؟ یا راهکاری برای پارتیشن کردن داده پیدا کنیم؟
شاید داده، ذاتاً طبقه‌بندی‌شده هست و شکسته‌شدن‌ش به دسته‌های کوچکتر، راهکاری قابل قبول باشه.
نکته اصلی این هست که تغییر پایگاه داده‌ای که بصورت تجاری درحال سرویس‌دهی هست، بسیار پرهزینه و همراه با ریسک بالاست.
بهتره ما کاملاً مطمئن باشم که «هیچ» راه‌حل دیگری برای حفظ و استفاده از پایگاه داده فعلی وجود ندارد.
اوکی، ما همه راه‌ها رو (برای حفظ) پایگاه داده فعلی رفتیم و نشد … چگونه بریم یکی دیگه انتخاب کنیم؟
ما توسعه‌دهنده‌گان، بطور طبیعی مانند پروانه که به سمت شعله کشیده میشه، به سمت ابزارهای جدید و معروف(درخشان) کشیده می‌شیم …
این موضوع وقتی در مورد پایگاه داده مطرح میشه، هیجان‌انگیز نبودن چیز بدی نیست.
ما باید اونی رو انتخاب کنیم که سابقه طولانی داشته باشه و در چالش‌ها امتحان‌ش رو پس داده باشه. (لات کوچه خلوت نباشه )
بسته به صنعتی که درش هستیم، وضعیت می‌تونه کمی متفاوت باشه، بانک‌ها و حوزه‌های مالی، به عنوان مثال، دغدغه‌های بیشتری دارند … بسته به چیزی که هست، باید (برای پایگاه داده انتخابی) یک بازار (منابع انسانی) آماده از متخصصین باتجربه وجود داشته باشه،
مهندسی نرم‌افزار باتوجه به حجم و ابعاد کار، یک انتخاب همراه با سود و زیان هست. وقتی درباره پایگاه داده مطرح میشه، بیشتر هم صادق هست …
همیشه یادتون باشه؛ هیچ منافعی، رایگان نیست … از تبلیغات گمراه‌کننده دور باشید.
همیشه توسعه‌ی عرضی بدون زحمت، همراه با هزینه(های) پنهان هستند …
برای پیدا کردن هزینه(های) پنهان، عمیق‌تر کاوش کنید …
بجای خوندن بروشور‌های تبلیغاتی، مستندات (رسمی) رو مطالعه کنید … همیشه یک صفحه‌ای وجود داره بنام «محدودیت‌ها»، این صفحه جواهر هست، همچنین صفحه «پرسش و پاسخ» هم خیلی کاربردی هست. این صفحات در مستندات، جایی هست که ما محدودیت‌های واقعی رو درباره یک پایگاه داده جدید، یاد می‌گیریم. اون محدودیت‌های طراحی شده رو خیلی بیشتر از اینکه راجع‌بهش حرف بزنیم، چاپ کرده … اگر داخل بروشور درباره ابعاد توسعه بصورت افقی نامحدود، تعهد داده شده، اینجا (مستندات) محلی برای راستی‌آزمایی اون ادعاهاست …
تجربه به ما می‌گه، پشت ادعاهای فانتزی، سلب مسئولیت بیشتری وجود داره … برای مثال خیلی از پایگاه‌های داده‌ی NoSQL، ابعاد بالاتری از پایگاه‌های رابطه‌ای قابل اطمینان قدیمی، دارند، اونها معمولاً ادعا می‌کنند که از توسعه مقیاس افقی خطی، پشتیبانی می‌کنند.
What is vertical scaling?
Probably the easiest way to scale a database is by using vertical scaling. Vertical scaling is the action of adding more resources to a server to handle an increasing load. Resources that you can add include CPUs, RAM, or hard disks.
What is horizontal scaling?
Another way to scale a database server is to do so horizontally. Scaling horizontally means adding more servers so that the load is distributed across multiple nodes.
اینجا یک انتخاب هزینه‌دار مشترک، از طرف اونهاست:
−− اول اینکه، اونها تضمین transactional بودن رو محدود یا حذف کرده‌اند.
−− دوم، اونها بارها قابلیت flexible بودن مدل‌های داده رو محدود کرده‌اند.
−− هیچ queryی در سراسر داده‌های entity، نیست.
−− وقتی قسمتی از یک داده بصورت مشترک در مجموعه‌های مختلف ذخیره میشه، برای پشتیبانی از الگوهای مختلف دسترسی، داده بشدت de-normalized شده …
برای یادگیری بیشتر درارتباط با یک پایگاه داده‌ی خاص، وارد اتاق‌های گفتگو شوید. کلی سوال مطرح کنید. روی پروژه‌های متن باز، issueها رو بخونید، تا جای ممکن درباره گزینه انتخابی مطالعه کنید. در این مقطع، به‌نسبت سرمایه‌گذاری کمی مورد نیاز هست.
وقتی ما انتخاب‌هامون رو گزیده کردیم، قدم بعدی چیه؟
بریم که یک شلیک داشته باشیم:
−− برای گزینه (پایگاه داده‌ی) انتخابی، یک نسخه آزمایشی واقعی، روی داده‌هامون ایجاد کنیم.
−− به‌همراه الگوهای دسترسی (شبیه‌سازی شده‌ی حوزه فعالیت) بصورت واقعی. ما اون داده رو داریم، درسته؟ بعد از اون، پایگاه داده فعلی ما، در درزهاش (مشکلات/حفره‌ها)، می‌ترکه. بنابراین شاید داشتن چند نمونه، مورد انتظار باشه. بله این هزینه داره و می‌تونه هفته‌ها وقت بگیره، اما ما نمی‌تونیم این قسمت رو نادیده بگیریم.
تغییر وایگاه داده‌ی درحال سرویس، بسیار پرخطر هست و بسیار بیشتر از آزمون‌های benchmark کار می‌برد.
اگر ما با (انتخاب) این پایگاه داده جدید، کسب و کارمون رو بخطر می‌اندازیم، اجازه بدید مطمئن بشیم که (درست) کار میکنه.
در طول آزمون bench-marking، به outlineها توجه کنید. P99رو برای همه‌چیز اندازه بگیرید. «مقدار میانگین» معنی نداره.
یک حجم واقعی (از مجموعه داده) رو سختگیرانه، تکثیر کنید و (سعی کنید) فشار رو افزایش بدید، و بعد ببینید کجا شروع به شکست میکنه.
تلاش کنید، فرآیند‌های پرخطرتر رو مثل شکست یک نود، یا آزمایش انحراف داده هنگام network partitionها انجام دهید.
رو دوباره بخونیم.
)