OrientDB or Not OrientDB

در ابتدا بگویم که اگر این مقاله را می‌خوانید که بدانید OrientDB چه قابلیت‌هایی دارد و چه‌کار می‌کند، شما را به سایت و داکیومنت این محصول ارجاع می‌دهم که بسیار بهتر از من به بیان قابلیت‌ها و کاربردهای آن پرداخته است. اما اگر با OrientDB یا Neo4j یا دیگر دیتابیس‌های گرافی آشنایی دارید، این متن دیدی از تجربه من نسبت به این دیتابیس به شما می‌دهد.
اگر به داکیومنت‌های این دیتابیس مراجعه کنید پر است از قابلیت‌های گوناگون و ادعای اینکه این دیتابیس هم گرافی است هم داکیومنتی، به نحوی که در نسخه ۲ آن و با آن ادعاها حس می‌کنید که حتی می‌تواند دیتابیس‌های search engine خود را نیز کنار بگذارید. پشتیبانی از lucene، الگوریتم‌های ایندکس‌گذاری با سرعت بالاتر و خیلی از موارد که شاید برای یک پروژه کوچک واقعی به نظر برسد، اما وقتی میزان داده شما از میلیون به میلیارد رسید دیگر بیشتر این ادعاها رنگ می‌بازد^۱.
داستان ما و OrientDB برمی‌گردد به زمانی که مسائل گرافی برایمان مطرح شد. مثلا فاصله بین دو موجودیت چقدر است، کوتاهترین مسیر از کجاست و خیلی دیگر از مسائل که همه به نحوی با گراف مرتبط بود و ماهیت گرافی داشت اما نمی‌شد با gephi و … حل کرد^۲.
چرا می‌گویم ماهیتِ گرافی؟ چون که رفتن به سمت یک دیتابیس گرافی یک دلیل موجه می‌خواست و آن هم داشتن مسائلی با ماهیت گرافی بود، چیزی که ما به آن رسیده بودیم! شروع R&D این موضوع ما را به دو دیتابیس Neo4j و OrientDB رساند. بدیهی بود که میان دو انتخاب، در مجموع بیشتر افراد Neo4j را به OrientDB ترجیح می‌دادند. نتیجه‌ی ما هم این بود که Neo4j بهتر است. اما OrientDB ادعایی داشت که وسوسه‌کننده بود و آن هم داشتن ویژگی‌های رایگان که Neo4j آن ویژگی‌ها را با چند ده هزار دلار ارائه می‌کرد. شاید مهم‌ترین ویژگی، توانایی shard کردن در چندین node مختلف بود. این ویژگی در Neo4j با قیمتی ارائه می‌شد که با توجه به قیمت دلار مشکل به نظر می‌رسید و ما را با توجه به حجم داده‌هایمان به سمت OrientDB سوق داد.

گربه شرودینگر

فرض کنید یک دیتابیس گرافی OrientDB با چندین میلیارد راس و یال داشته باشید، به این دیتابیس یک کاربر با دسترسی کوئریِ read و یک کوئری traverse بدون limit وجود دارد. حال تصور کنید OrientDB در صورت دریافت کوئری بدون limit با احتمال ۵۰ درصد down می‌شود یا up می‌ماند. اگر کاربر بین ساعت ۱۲ و ۱۲:۰۱ این کوئری را اجرا کند، و شما در ساعت ۱۲:۰۱ به دیتابیس OrientDB وصل شوید OrientDB یا up است و شما به راحتی به سراغ ناهار می‌روید یا down است و تایم ناهار را از دست می‌دهید.

مرگ تدریجی یک رویا

شاید ویژگی بارز برخی رویاها که براساس ادعاهای اشتباه یا محاسبات غلط باشد، مرگ تدریجی آن‌هاست، اتفاقی که برای ما و OrientDB هم افتاد. هنگامی که فهمیدیم وقتی حجم دیتابیس از چندصد میلیون بیشتر می‌شود و shard کردن با مشکل مواجه می‌شود، به انکار واقعیت پرداختیم. باور نداشتیم که آن همه ادعا تنها برای چند صد میلیون داده معتبر است و وقتی به میلیارد نزدیک می‌شویم با مشکلات فراوان عدم تطابق nodeها برخورد می‌کنیم. زیر و رو کردن صفحه issueهای OrientDB نیز فایده‌ای نداشت. بسیاری از مسائل که بی‌پاسخ بودند و بسیاری از مسائل که ثبت کننده‌شان خودمان بودیم. باور این مسئله همچنان دشوار بود. به سمت مشاورهای داخلی و خارجی رفتیم. هیچکدام فایده نداشت. اکثرا تجربه توزیع کردن در مقیاسی که نیاز ما بود را نداشتند. آخرین تیر در ترکش ما تماس با کدنویس‌ها و مدیر تیم OrientDB بود. توانستیم وقتی از مدیر تیمشان بگیریم و به طرح مشکلات بپردازیم. آب پاکی را بر دستانمان ریخت. راه حل حداقل کردن نیازهایمان، بسنده کردن به چند ده میلیارد داکیومنت، استفاده از حالت غیرتوزیع شده به جای حالت توزیع شده و ایندکس کردن دیتا به روشی خاص از جمله جواب‌هایی بود که سرپرست کدنویس‌های OrientDB به ما داد.

سراب شارد

وقتی می‌خواهید تعداد زیادی راس و یال ذخیره کنید به این فکر می‌افتید که سیستم مورد نیاز برای OrientDB را ارتقا دهید. اگر بخواهید از مزیت‌های شارد کردن به تمامی استفاده کنید به سراغ افزودن چندین node به یک کلاستر می‌روید. این امر با OrientDB برقرار است اگر این تعداد زیاد به معنی چند ده میلیون راس و یال باشد، نه چند ده میلیارد.

سراب ایندکس

نکته‌ای که درهنگام صحبت با مدیر کدنویس‌های OrientDB متوجه شدیم این بود که انتظار ایندکس کردن داده‌ها در آن scale از داده به سادگی چند تنظیم ساده دیتابیس نیست. مجموعه‌ای از راه‌حل‌ها را باید به کار بست تا به این هدف دست یافت.

سراب پشتیبان‌گیری

داشتن پشتیبان از دیتابیس با استفاده از shard به سراب پیوست. اما OrientDB دو ویژگی برای پشتیبان‌‌گیری از دیتابیس در اختیار گذاشته است. یکی پشتیبان‌گیری از کل دیتابیس و دیگری پشتیبان‌گیری به صورت افزایشی که البته این مورد دوم به صورت یک ویژگی غیررایگان است. امکان پشتیبان‌گیری به صورت غیرافزایشی با api ارائه شده توسط OrientDB نیزبا برخی مشکلات مواجه است. برای مثال می‌توان به کند بودن این api در مقیاس بالا و ایجاد اختلال‌هایی در پشتیبان‌گیری در هنگام درج داده جدید در OrientDB اشاره کرد.

زیبایی‌های دیتابیس گرافی

اما در انتها به این سوال می‌رسیم با این همه مشکلات آیا OrientDB ارزشش را داشت. شاید اگر به گذشته برمی‌گشتیم و در ابتدا با انبوه این عناوین مشکلات مواجه می‌شدیم عطایش را به لقایش می‌بخشیدیم. اما OrientDB زیبایی‌هایی داشت که از کرده خود پشیمان نیستیم. حل مسائل گرافی، راحتی traverse کردن در گراف، اطاعات جالب به دست آمده از گراف و بسیاری دیگر از ویژگی‌ها لبخند رضایتی بر لبانمان نشاند. همه مشکلات گفته شده در این مقاله و برخی دیگر از مشکلات که در این مقاله به آن اشاره نشد، همه و همه چالش‌هایی بود که در این مسیر با آن مواجه شدیم و یکی پس از دیگری به حل آن‌ها پرداختیم.
در قسمت بعد از این مقاله می‌خواهیم به شرح دقیق‌تر این مشکلات و راه‌حل‌هایی که برای حل این مشکلات به کار بستیم بپردازیم.

پانویس ۱. نسخه ۳ بنا به ادعای تولید‌کنندگان این دیتابیس به طور کلی متحول شده است و دیگر به صورت document based نیست ولی در تجربه اولیه، در نسخه‌‌ای که ادعا می‌شد مناسب پروداکت است، با باگ‌های پیش پاافتاده‌ای برخورد کردم که به کل ناامید شدم.

پانویس ۲. OrientDB ادعا می‌کند که به راحتی به gephi وصل می‌شود اما این ادعا با توجه به ورژن OrientDB ، gephi و … با اما و اگر مواجه می‌شود.