درود بیکران بر شما. این قسمت اول از سری دلمغز نوشته هاست که اصلا جنبه آموزشی نداره و فقط قصد داره چالش ها و اتفاقات رخ داده برای یک برنامه نویس بکند-Backend رو تبدیل به متن بکنه. پس ممکنه که در اون حرفای غلط و کمتر دقیق باشه. به همین خاطر خواهشمندم از دوستان آگاه تا در نظرات من رو تصحیح کنن.
امروز تو شرکت صحبت بر این شد که ساختار دیتابیسی یکی از پروژه هامون که خیلی وقت هست با الاستیک کار میکنه رو بهینه کنیم چون در هنگام استفاده ازش به چالش هایی خوردیم که نیاز به یک بازنگری درباره اش هست.
اولین چالش ما این بود که نیازمند این بودیم که در دیتابیس non relational کوئری هایی از نوع relational بزنیم. بعد از مدتی کوتاه به این فکر افتادیم که شاید اصلا معماری دیتابیسمون نیاز به تغییر داره و حتما نیاز نیست که از دیتابیس relational استفاده کنیم.
پس از مدتی تحقیق و جستجو به یک دیتابیس جالب بر خوردم که بهتون معرفی میکنم.
در زمان هایی نچندان دور در سال 2016 کمپانی روسی Yandex تصمیم گرفت که دیتابیس پیشرفته خودشو به جهانیان ارائه بده. به گفته خودشون اونها از این دیتابیس برای کارهای آماری و گزارش گیری استفاده میکنند.
این دیتابیس ادعا میکنه که از دیتابیس های رایج حدود ۱۰۰ الی ۱۰۰۰ برابر سریع تره. شاید این ادعا یکم ترسناک یا حتی غیرممکن بیاد، اما تست ها نشون میده که حداقل در Aggregation و Histogram این آمار درست هست و کلیک هاوس به شدت سریع پاسخ میده اما همچنان مثل دیتابیس های NoSql دیگه مثل الاستیک در Update, Delete کند هست.
متاسفانه به دلیل نوپا بودن این دیتابیس هنوز نمیشه روش به عنوان یک دیتابیس اصلی برای پروژه های بزرگ استفاده کرد. اما تا الان نتایجی که ازش دیدیم به شدت راضی کننده بوده. نمونه شرکت های بزرگی که ازش استفاده کردن تا الان میشه از Cloudflare و Uber و چند شرکت بزرگ دیگه نام برد.
طبق چیزایی که من خوندم و مشورت با برخی از همکاران میتونیم از مکانیزم های داینامیک استفاده کنیم.
به طور مثال میتونیم دیتاها رو به دیتاهای کم اهمیت و پر اهمیت و یا دیتاهای بازه زمانی فلان تا فلان موقع دسته بندی کنیم و هنگامی که کاربر درخواست میده بسته به نوع درخواست و چیزهایی که میخواد دیتاهای مناسب رو نشونش بدیم. اینجوری میشه سرعت کوئری ها رو بالا برد.
یک راه دیگه هم که میشه استفاده کرد میزان بالای کش-Cache هست. میتونیم اکثر دیتا رو کش کنیم و به کاربر مقادیر کش شده رو نشون بدیم. این راه یک محدودیت بزرگ داره و اونم اینه که اگه کاربر فیلتر های غیر قابل پیش بینی بزنه دیگه کشی وجود نداره که بهش نشون بدیم.
راه حل های دیگه ای مثل استفاده از MSSQL یا Oracle بود که وقت نشد بیشتر روش وقت بذارم. در قسمت های بعدی بهش میپردازم. همچنین در قسمت بعدی به راه حل هایی که کمپانی های بزرگ مثل فیسبوک و توییتر و اینستاگرام و ... ساخته و پرداخته اند اشاره میکنم.
ممنون که تا اینجا با دل و مغز من همراهی کردین.
