کاساندرا اگر فقط اوراکل را بشناسید چگونه نمردید

هی هابر

نام من میشا بوتریموف است، می خواهم کمی در مورد کاساندرا برای شما بگویم. داستان من برای کسانی که هرگز با پایگاه های داده NoSQL مواجه نشده اند مفید خواهد بود - دارای ویژگی های پیاده سازی و مشکلات زیادی است که باید در مورد آنها بدانید. و اگر چیزی غیر از Oracle یا هر پایگاه داده رابطه‌ای دیگری ندیده‌اید، این چیزها زندگی شما را نجات خواهند داد.

چه چیزی در مورد کاساندرا خوب است؟ این یک پایگاه داده NoSQL است که بدون یک نقطه شکست طراحی شده است که به خوبی مقیاس می شود. اگر نیاز به اضافه کردن چند ترابایت برای برخی پایگاه داده دارید، به سادگی گره ها را به حلقه اضافه کنید. آن را به مرکز داده دیگری گسترش دهیم؟ گره ها را به خوشه اضافه کنید. RPS پردازش شده را افزایش دهید؟ گره ها را به خوشه اضافه کنید. در جهت مخالف نیز کار می کند.

او در چه چیز دیگری خوب است؟ این در مورد رسیدگی به بسیاری از درخواست ها است. اما چقدر است؟ 10، 20، 30، 40 هزار درخواست در ثانیه زیاد نیست. 100 هزار درخواست در ثانیه برای ضبط - بیش از حد. شرکت هایی هستند که گفته اند در هر ثانیه 2 میلیون درخواست را نگه می دارند. آنها احتمالا باید آن را باور کنند.

و در اصل، کاساندرا یک تفاوت بزرگ با داده های رابطه ای دارد - به هیچ وجه شبیه آنها نیست. و این بسیار مهم است که به خاطر بسپارید.

هر چیزی که یکسان به نظر می رسد یکسان عمل نمی کند

یک بار یکی از همکاران نزد من آمد و از من پرسید: "اینجا یک زبان پرس و جو CQL Cassandra است، و یک عبارت انتخابی دارد، دارای Where، دارای و. من نامه می نویسم و ​​کار نمی کند. چرا؟". برخورد با کاساندرا مانند یک پایگاه داده رابطه‌ای بهترین راه برای خودکشی خشونت‌آمیز است. و من آن را تبلیغ نمی کنم، در روسیه ممنوع است. شما فقط چیزی را اشتباه طراحی می کنید.

به عنوان مثال، مشتری به ما مراجعه می کند و می گوید: «بیایید یک پایگاه داده برای سریال های تلویزیونی بسازیم، یا یک پایگاه داده برای فهرست دستور پخت. ما در آنجا غذاهای غذایی خواهیم داشت یا لیستی از سریال ها و بازیگران در آن وجود دارد.» ما با خوشحالی می گوییم: "بیا برویم!" فقط دو بایت، چند علامت بفرستید و کارتان تمام شد، همه چیز خیلی سریع و قابل اعتماد کار خواهد کرد. و همه چیز خوب است تا زمانی که مشتریان می آیند و می گویند که خانم های خانه دار نیز مشکل معکوس را حل می کنند: آنها لیستی از محصولات دارند و می خواهند بدانند چه غذایی را می خواهند بپزند. تو مرده ای.

این به این دلیل است که Cassandra یک پایگاه داده ترکیبی است: به طور همزمان یک مقدار کلیدی را ارائه می دهد و داده ها را در ستون های گسترده ذخیره می کند. در جاوا یا کاتلین، می توان آن را اینگونه توصیف کرد:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

یعنی نقشه ای که شامل یک نقشه مرتب شده نیز باشد. اولین کلید این نقشه، کلید ردیف یا کلید پارتیشن - کلید پارتیشن بندی است. کلید دوم، که کلید یک نقشه از قبل مرتب شده است، کلید Clustering است.

برای نشان دادن توزیع پایگاه داده، سه گره را ترسیم می کنیم. اکنون باید بدانید که چگونه داده ها را به گره ها تجزیه کنید. زیرا اگر همه چیز را در یک جا جمع کنیم (به هر حال، می تواند هزار، دو هزار، پنج - به تعداد دلخواه شما باشد)، این واقعاً مربوط به توزیع نیست. بنابراین، ما به یک تابع ریاضی نیاز داریم که یک عدد را برگرداند. فقط یک عدد، یک int طولانی که در محدوده ای قرار می گیرد. و یک گره مسئول یک محدوده، دومی برای دومین و nامین برای nامین خواهیم داشت.

این عدد با استفاده از یک تابع هش گرفته می شود که به چیزی که ما آن را کلید پارتیشن می نامیم اعمال می شود. این ستونی است که در دستورالعمل کلید اصلی مشخص شده است و این ستونی است که اولین و اساسی ترین کلید نقشه خواهد بود. تعیین می کند که کدام گره کدام داده را دریافت کند. یک جدول در Cassandra با نحوی تقریباً مشابه در SQL ایجاد می شود:

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

کلید اصلی در این مورد از یک ستون تشکیل شده است و همچنین کلید پارتیشن بندی است.

عملکرد کاربران ما چگونه خواهد بود؟ برخی به یک گره، برخی به گره دیگر و برخی به یک سوم خواهند رفت. نتیجه یک جدول هش معمولی است، همچنین به عنوان نقشه شناخته می شود، همچنین به عنوان یک فرهنگ لغت در پایتون شناخته می شود، یا یک ساختار ارزش Key ساده که از آن می توانیم تمام مقادیر را بخوانیم، بخوانیم و بنویسیم.

انتخاب کنید: زمانی که اجازه فیلتر کردن به اسکن کامل تبدیل می‌شود، یا چه کاری نباید انجام شود

بیایید چند عبارت انتخابی بنویسیم: select * from users where, userid = . به نظر می رسد مانند اوراکل: ما انتخاب می نویسیم، شرایط را مشخص می کنیم و همه چیز کار می کند، کاربران آن را دریافت می کنند. اما اگر برای مثال کاربری با سال تولد مشخصی را انتخاب کنید، کاساندرا شکایت می کند که نمی تواند درخواست را برآورده کند. از آنجا که او اصلاً چیزی در مورد نحوه توزیع داده های مربوط به سال تولد نمی داند - او فقط یک ستون به عنوان کلید دارد. سپس او می گوید: "باشه، من هنوز می توانم این درخواست را برآورده کنم. اجازه فیلتر را اضافه کنید." ما دستورالعمل را اضافه می کنیم، همه چیز کار می کند. و در این لحظه یک اتفاق وحشتناک رخ می دهد.

وقتی روی داده های آزمایشی اجرا می کنیم، همه چیز خوب است. و هنگامی که شما یک پرس و جو را در مرحله تولید اجرا می کنید، جایی که ما مثلاً 4 میلیون رکورد داریم، آن وقت همه چیز برای ما خوب نیست. زیرا اجازه فیلتر کردن دستوری است که به Cassandra اجازه می‌دهد تمام داده‌های این جدول را از همه گره‌ها، همه مراکز داده (اگر تعداد زیادی از آنها در این خوشه وجود داشته باشد) جمع‌آوری کند و تنها پس از آن آن را فیلتر کند. این یک آنالوگ Full Scan است و به ندرت کسی از آن راضی است.

اگر فقط به کاربران با شناسه نیاز داشتیم، با این کار خوب بودیم. اما گاهی اوقات ما نیاز به نوشتن پرس و جوهای دیگر و اعمال محدودیت های دیگری برای انتخاب داریم. بنابراین، ما به یاد می آوریم: این همه نقشه ای است که دارای یک کلید پارتیشن بندی است، اما داخل آن یک نقشه مرتب شده است.

و او همچنین یک کلید دارد که ما آن را کلید خوشه‌بندی می‌نامیم. این کلید که به نوبه خود از ستون هایی تشکیل شده است که ما انتخاب می کنیم و با کمک آن کاساندرا می فهمد که چگونه داده های آن به صورت فیزیکی مرتب شده اند و در هر گره قرار می گیرند. یعنی برای برخی از کلیدهای پارتیشن، کلید Clustering دقیقاً به شما می گوید که چگونه داده ها را به این درخت فشار دهید، چه مکانی را در آنجا خواهد گرفت.

این در واقع یک درخت است، یک مقایسه کننده به سادگی در آنجا نامیده می شود که مجموعه ای از ستون ها را به شکل یک شی به آن پاس می دهیم و به عنوان لیستی از ستون ها نیز مشخص می شود.

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

به دستورالعمل کلید اصلی توجه کنید؛ اولین آرگومان آن (در مورد ما، سال) همیشه کلید پارتیشن است. این می تواند از یک یا چند ستون تشکیل شده باشد، مهم نیست. اگر چندین ستون وجود دارد، باید دوباره در پرانتز حذف شود تا پیش پردازشگر زبان بفهمد که این کلید Primary است و پشت آن همه ستون‌های دیگر کلید Clustering هستند. در این صورت آنها به ترتیب ظاهر شدن در مقایسه کننده منتقل می شوند. یعنی ستون اول اهمیت بیشتری دارد، دومی کمتر و .... برای مثال نحوه نوشتن ما با فیلدهایی برای کلاس های داده برابر است: فیلدها را فهرست می کنیم و برای آنها می نویسیم که کدام بزرگتر و کدام کوچکتر است. در Cassandra، اینها، به طور نسبی، فیلدهای کلاس داده هستند که معادل های نوشته شده برای آن اعمال می شود.

ما مرتب سازی را تعیین می کنیم و محدودیت هایی را اعمال می کنیم

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

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

کار ما دوباره ظاهر می شود where, and، و ما کاربران را دریافت می کنیم، و همه چیز دوباره خوب است. اما اگر بخواهیم فقط از بخشی از کلید Clustering استفاده کنیم، و یک کلید کمتر مهم، آنگاه کاساندرا فوراً شکایت می‌کند که نمی‌تواند مکانی را در نقشه ما پیدا کند که این شی، که این فیلدها را برای مقایسه‌کننده تهی و این یکی دارد. که به تازگی تنظیم شده بود، - جایی که او دراز می کشد. من باید تمام داده ها را دوباره از این گره بیرون بکشم و آن را فیلتر کنم. و این یک آنالوگ Full Scan در یک گره است، این بد است.

در هر موقعیت نامشخص، یک جدول جدید ایجاد کنید

اگر بخواهیم بتوانیم کاربران را با شناسه یا سن یا حقوق هدف قرار دهیم، چه باید بکنیم؟ هیچ چی. فقط از دو جدول استفاده کنید. اگر بخواهید به سه روش مختلف به کاربران دسترسی پیدا کنید، سه جدول وجود دارد. روزهایی که در فضای پیچ صرفه جویی می کردیم گذشته است. این ارزان ترین منبع است. هزینه آن بسیار کمتر از زمان پاسخگویی است که می تواند برای کاربر مضر باشد. دریافت چیزی در یک ثانیه برای کاربر بسیار خوشایندتر از 10 دقیقه است.

ما فضای غیرضروری و داده‌های غیرعادی‌سازی شده را برای توانایی مقیاس‌بندی خوب و عملکرد قابل اعتماد مبادله می‌کنیم. از این گذشته، در واقع، خوشه ای متشکل از سه مرکز داده، که هر کدام دارای پنج گره است، با سطح قابل قبولی از حفظ داده ها (زمانی که چیزی از بین نرود)، می تواند از مرگ یک مرکز داده به طور کامل جان سالم به در ببرد. و دو گره دیگر در هر یک از دو گره باقی مانده. و تنها پس از این مشکلات شروع می شود. این یک افزونگی بسیار خوب است، ارزش چند درایو SSD و پردازنده اضافی را دارد. بنابراین، برای استفاده از Cassandra، که هرگز SQL نیست، که در آن هیچ رابطه، کلید خارجی وجود ندارد، باید قوانین ساده ای را بدانید.

ما همه چیز را طبق درخواست شما طراحی می کنیم. نکته اصلی داده ها نیست، بلکه نحوه کار برنامه با آن است. اگر نیاز به دریافت داده های مختلف به روش های مختلف یا همان داده ها به روش های مختلف دارد، باید آن را به گونه ای قرار دهیم که برای برنامه مناسب باشد. در غیر این صورت در Full Scan شکست می خوریم و کاساندرا هیچ مزیتی به ما نمی دهد.

غیرعادی کردن داده ها هنجار است. ما فرم های معمولی را فراموش می کنیم، دیگر پایگاه داده های رابطه ای نداریم. اگر چیزی را 100 بار زمین بگذاریم، 100 بار دراز می کشد. هنوز هم ارزان تر از توقف است.

کلیدهای پارتیشن بندی را طوری انتخاب می کنیم که در حالت عادی توزیع شوند. ما نمی خواهیم هش کلیدهای ما در یک محدوده باریک قرار گیرد. یعنی سال تولد در مثال بالا مثال بدی است. به طور دقیق تر، اگر کاربران ما به طور معمول بر اساس سال تولد توزیع شوند، خوب است، و اگر در مورد دانش آموزان کلاس 5 صحبت کنیم، بد است - پارتیشن بندی در آنجا خیلی خوب نخواهد بود.

مرتب سازی یک بار در مرحله ایجاد کلید خوشه ای انتخاب می شود. اگر نیاز به تغییر داشته باشد، باید جدول خود را با کلید دیگری به روز کنیم.

و مهمترین چیز: اگر ما نیاز به بازیابی داده های مشابه به 100 روش مختلف داشته باشیم، 100 جدول مختلف خواهیم داشت.

منبع: www.habr.com