در این قسمت، رابرت بلومن در حاشیه کنفرانس Mongo در سانفرانسیسکو با دوآیت مریمن درباره‌ی NoSQL و اقبالی که به آن شده است صحبت می‌کنند. دوآیت مدیرعامل و از بنیانگذاران شرکت MongoDB است که حامی صنعتی پایگاه داده متن‌باز MongoDB است. در این مصاحبه به این موارد اشاره می‌شود: NoSQL و ۳ نوع ذخیره‌گاه غیررابطه‌ای مطرح در آن، قضیه CAP و تضمین‌های سازگاری ضعیف‌تری که می‌توان در پایگاه‌ داده‌های توزیع‌شده داشت، ذخیره‌گاه‌‌های سندگرا (Document-oriented)، نیازهای ذخیره‌سازی برنامه‌های نوین تحت وب و پایگاه داده متن‌باز MongoDB.
به رادیوی مهندسی نرم‌افزار خوش آمدی دوآیت!
متشکرم.
من با شما در مورد NoSQL و پایگاه Mongo صحبت می‌کنم. لطفاً ابتدا کمی در مورد سابقه‌تان با مخاطبان‌مان صحبت کنید.
از نظر سابقه فنی، من به عنوان یک توسعه‌دهنده شروع کردم. من از بنیانگذاران و مدیرفنی DoubleClick بودم.. فناوری اصلی آن را ساختم و بعد از DoubleClick شرکت جدیدی با نام 10gen را شروع کردیم که منشأ و حامی پروژه MongoDB است.
شما یک ارائه دارید که در اینترنت هم در دسترس است و گذار به دنیای غیررابطه‌ای نام دارد. چرا دنیا به این سمت حرکت می‌کند؟
سرعت‌دهنده‌ی اصلی آن، میل به مقیاس‌پذیری افقی (Horizontal Scalability) است. چرا که مقیاس دادن افقی یک پایگاه سنتی رابطه‌ای مسأله بسیار سختی است. اگر فرضی در مورد شِمای داده‌ها نداشته باشید، انجام عملیات‌های الحاق توزیع‌شده (Distributed Join) خیلی سخت است. به علاوه، انجام تراکنش‌های توزیع‌شده پرهزینه است. بنابراین به نظر من به راه‌حل‌های ذخیره داده‌ای نیاز بود که به سادگی به شکل افقی افزایش مقیاس داده شوند و اگر الحاق‌ها و تراکنش‌های پیچیده را کنار بگذاریم می‌توانیم این کار را بکنیم. بنابراین این‌ها ویژگی‌های راه‌‌حل‌های غیررابطه‌ای جدید است. علتی که این فضا شکل گرفت، این بود که یک میل به مقیاس‌پذیری افقی وجود داشت. به علاوه، فکر می‌کنم فرصتی هم برای نوآوری در ارتباط با مثلاً مدل‌های داده، وجود دارد و حال که کارهایی می‌کنیم که رابطه‌ای نیست مزایای دیگری از جمله سادگی توسعه را هم بدست آورده‌ایم.
چرا طی ۲۰ سال گذشته، پایگاه‌های رابطه‌ای بازار ذخیره‌گاه‌ها را تصرف کرده‌اند؟
سئوال خوبی است. از لحاظ نظری، پایگاه‌های رابطه‌ای ۴۰ سال عمر دارند بنابراین یکی از پرعمرترین و موفق‌ترین فناوری‌های تاریخ به شمار می‌روند. چیزی که عمرش بیش از آن باشد را در ذهن ندارم و خیلی خوب هم کار کرده‌اند. فکر می‌کنم یکی از عوامل کلیدی‌اش این است که مزایای چشمگیری در ناهمبسته کردن (Decoupling) مفاهیم ذخیره‌گاه و مدل داده با امور برنامه و کد وجود دارد. سیستم‌های معظم (Enterprise) شامل برنامه‌های کاربردی زیادی هستند و از زبان‌های برنامه‌نویسی زیادی استفاده می‌کنند و این زبان‌ها در طی زمان تغییر می‌کنند. هرچند سال یکبار، زبان جدیدی می‌آید. بنابراین نمی‌خواهیم که داده‌های‌مان به کد، زیادی همبسته شود. فکر می‌کنم در روزهای اولیه پایگاه‌های اشیاء (Object Databases) این مسأله کمی وجود داشته است. اما چیز خوبی که در مورد رابطه‌ای‌ها هست این است که هیچ زبان برنامه‌نویسی رابطه‌ای وجود ندارد و در واقع رابطه‌ها انواع داده‌ای هستند. این به خوبی از محیط کدنویسی مجزا شده است اما بر خلاف انتظار مشخص شد که مفید است چون ممکن است تکه‌کدهای خیلی زیادی داشته باشید و زبان‌های مختلف زیادی داشته باشید و کد پیچیده می‌شود و اگر قرار باشد برای فهمیدن کد، مجبور باشیم داده‌ها را بفهمیم، مشکل می‌شود. به علاوه روشن شد که SQL چیز واقعاً قدرتمندی است که واسطه زیبایی بین کلاینت و سرور این برنامه‌ها می‌آورد و استانداردهایی حول آن دارد که این چیز خوبی است و چیزی است که بر روی مفاهیم رابطه‌ای بنا شده است.
شما گفتید که یکی از محرک‌های فاصله گرفتن از [پایگاه‌های] رابطه‌ای، نیاز به مقیاس‌پذیری به خارج (Scale out) است. درباره مشکلات مقیاس‌پذیری توضیح دهید که در کار با ذخیره‌گاه‌های رابطه‌ای برخورده‌اید.
در بیشتر پایگاه‌های رابطه‌ای نمی‌توانید یک خوشه (Cluster) با ده گره داشته باشید که مانند یک ماشین منطقی به نظر برسد. البته به طور خاص در فضای انبار کردن داده‌ها (Datawarehousing) و هوش تجاری (Business Intelligence) راه‌حل‌هایی وجود دارد که چنین امکاناتی را فراهم می‌کند. بنابراین در آن فضاها، مشکلی نیست اما آن فضا مربوط به مسأله خاصی می‌شود که روشن شده در آن‌جا مشکل کمتری وجود دارد. اما [در فضاهای] برخط و OTP خیلی سخت است که خوشه بسازید. در‌واقع دو نوع خوشه داریم. یک نوع، خوشه‌هایی است که بر روی تنها یک شبکه محلی (LAN) قرار می‌گیرد ونوع دیگر خوشه‌هایی است که بر روی چندین مرکز داده گسترش می‌یابد که کارش سخت‌تر هم می‌شود. خیلی سخت است که الحاق‌های توزیع‌شده را سریع انجام دهیم.
شما در مورد مقیاس‌پذیری و مقیاس‌پذیری به خارج (Scale out) صحبت کردید. آیا دسترس‌پذیری بالا (High Availability) در دنیای وب، عامل محرک دیگری در فاصله گرفتن از ذخیره‌گاه‌های رابطه‌ای است؟
فکر می‌کنم هست. راه‌حل‌های HA خیلی خوبی برای پایگاه‌های سنتی وجود دارد و فکر می‌کنم افراد آن را در این فضای جدید غیررابطه‌ای، کمی پیش‌تر هم برده‌اند. بنابراین فکر می‌کنم محرک اصلی حول مقیاس‌پذیری بوده‌است. مادامی که افراد به علت نیاز به مقیاس‌پذیری، حاضر به پذیرش این تغییر مفاهیم می‌شوند، مزایای دیگری هم می‌یابند. گرایش عمومی که در معماری کامپیوتر هست، به نحوی است که نیاز دارید مقیاس‌پذیری افقی داشته باشید. برای مدت طولانی، مقیاس‌پذیری عمودی، کاملاً شدنی بود؛ شما می‌توانستید برای [پایگاه داده] اوراکل خود، یک ماشین بزرگ‌تر بگیرید و خوب بود. اما آنچه الان رخ داده این است که هسته‌های CPU سریع شده‌اند؛ طوریکه نمی‌توانید هسته‌های CPU سریع‌تری بگیرید اما می‌توانید هزارتا هسته را خیلی ارزان بخرید. این به آن معنی است که نیاز به مقیاس‌پذیری افقی داریم.
با [مطرح شدن] سرویس‌های ابری، یک محرک اقتصادی هم هست که افراد را به استقرار بر روی خوشه‌هایی از گره‌های کم‌قدرت تحریک می‌کند.
بله. یک هم‌افزایی بین پردازش ابری و برخی از این تکنولوژی‌های جدید وجود دارد. مقیاس‌پذیری افقی و قابلیت ارتجاع (Elasticity) یک ویژگی کلیدی در پردازش ابری است که واقعاً آن را در پایگاه‌های سنتی نداریم. مثلاً بر روی EC2 آمازون، شما سخت‌افزارهای معمول (Commodity) را می‌گیرید بنابراین در واقع [تنها] راهی که برای ساختن یک سیستم بزرگ دارید، استفاده از تعداد زیادی جعبه و نه یک جعبه خیلی بزرگ است. بنابراین در این مورد همخوانی وجود دارد. در واقع، در حال حاضر این لایه ذخیره داده‌ها است که پیوند ضعیفی با فضای ابری دارد. منظورم این است که برخی از این راه‌حل‌های جدید خیلی جوان هستند و راه‌حل‌های قدیمی، با پردازش ابری جور نمی‌شوند.
آیا اینجا باید بگوییم که انواع پایگاه‌های رابطه‌ای به عنوان یک رده از محصولات، کم و بیش کار یکسانی را با کمی تفاوت انجام می‌دهند اما وقتی در مورد NoSQL صحبت می‌کنیم، در مورد رده بزرگتری از سیستم‌ها با تفاوت‌های بیشتری صحبت می‌کنیم.
تفاوت‌های خیلی بیشتری وجود دارد. فکر می‌کنم در فضای پایگاه‌های رابطه‌ای هم تفاوت‌هایی وجود دارد خصوصاً اگر به فضای گزارش‌گیری نگاه کنید که کارهای سفارشی زیادی انجام شده است اما [در کل،] خیلی همگن‌تر از فضای NoSQL است. یک دلیل بزرگش این است که در ابتدای کار هستیم. فکر می‌کنم آنچه امروزه با NoSQL انجام می‌دهیم با روزهای ابتدایی پایگاه‌های رابطه‌ای شباهت دارد؛ وقتی که Ingres و Informix و Sybase و DB2 و Oracle را داشتیم. اینطور نبود که [در آن روزها] همه از SQL به عنوان زبان پرس‌وجو استفاده کنند بلکه دسته‌ای از پایگاه‌های داده رابطه‌ای دیگر بودند که از زبان‌های پرس‌وجوی دیگری استفاده می‌کردند و بعد یک لرزه‌ شدید به وقوع پیوست و از پسِ آن روشن شد که اندکی برنده می‌شوند که همان SQL باشد. ما هم در همان مرحله لرزه اولیه قرار داریم. برخی از محصولات هستند که دیگر در فضای NoSQL وجود ندارند، آن‌ها بعد از ۱۰ سال نتوانسته‌اند محبوب شوند اما برخی هم به آنچه قرار بوده، تبدیل شده‌اند. فکر می‌کنم کل این فضا خیلی سریع دارد رشد می‌کند که خیلی مهیج است.
در دنیای رابطه‌ای، قطعاً برخی جایگزین‌های متن‌باز عالی وجود دارد اما برخی از بازیگران خیلی بزرگ وجود دارند که تجاری و متن‌بسته هستند. در حالیکه در NoSQL غلبه با مدل‌های متن‌باز است و پایگاه‌های خانگی (In-house) مانند پایگاه آمازون، بصورت سرویس توسط فراهم‌کنندگان فضاهای ابری فراهم می‌شود. آیا این قضیه را ماندگار می‌‌بینید یا می‌بینید که موجودات تجاری بزرگی دارند می‌آیند که بر این فضا غالب شوند.
خیلی جالب است. وقتی من محبوب‌ترین پایگاه‌های داده را نگاه می‌کنم در ۵ سال آینده ۳ بخش را می‌بینم. یکی پایگاه‌های سنتی بر خط رابطه‌ای OLTP است که همچنان خواهند بود و همچنان برای برخی کاربردها به کار می‌آیند اما نه در همه کاربردهایی که قبلاً مرسوم بوده‌اند. همچنین بخش دیگری است که مربوط به تحلیل داده‌ها، گزارش‌گیری‌های برون‌خط (Off-line)، انبارکردن داده‌ها و هوش تجاری است. این هم بخش دوم است که وجود دارد و متمایز است و من فکر می‌کنم کاملاً رابطه‌ای باقی بماند اما این‌ها مجموعه دیگری از فناوری‌ها از شرکت‌هایی مانند Greenpulm و Aster Data وVertica هستند. در فضای سوم، که فکر می‌کنم در ۵ سال آینده استفاده کلانی پیدا کند، NoSQL قرار دارد که ذخیره‌گاه‌های غیررابطه‌ای یا پسارابطه‌ای هستند که مقیاس‌پذیر افقی هستند و بیشتر برای اعمال برخط مناسب هستند.
در فضای غیررابطه‌ای، شما در مورد طبقه‌بندی سیستم‌ها حول چند محور مختلف صحبت کرده‌اید. یکی از این محورها با قضیه CAP فراهم شده است. می‌خواهم کمی در قضیه CAP عمیق شویم تا بتوانیم آن را بفهمیم و بعد، از آن استفاده کنیم تا در مورد انواع مختلف ذخیره‌گاه‌ها صحبت کنیم.
به اختصار، قضیه CAP چه چیزی را نشان می‌دهد؟
قضیه CAP ، فرضی از اریک بروئر است که بعداً بهبود داده شد و به یک قضیه تبدیل شد. اساساً می‌گوید که در یک سیستم توزیع‌شده، اگر ۳ ویژگی سازگاری (Consistency)، دسترس‌پذیری (Availability) و تحمل گسست شبکه (Network Partition) را در نظر بگیرید که همان حروف C و A و P را می‌سازند، نمی‌توانید همه این‌ها را با هم داشته باشید. این اثبات می‌شود.
چون ما در اینجا در مورد سیستم‌های توزیع‌شده صحبت می‌کنیم، شبکه درگیر است و وقتی شبکه گسست پیدا می‌کند، بخشی از آن پایین است. بنابراین آنچه واقعاً بیان می‌کند این است که اگر شبکه خراب شود، پایگاه داده‌تان کار نمی‌کند. اگر یک پایگاه داده توزیع‌شده باشد چنین چیزی غیرمنتظره نیست اما ما خودمان انتخاب می‌کنیم که «کار نکردن» چه معنی داشته باشد. می‌توانیم انتخاب کنیم که در این شرایط یا پایین باشد و در دسترس نباشد و یا اینکه بالا باشد اما نتایجی که می‌دهد، کاملاً سازگار نباشد. ما می‌توانیم یک مدل سازگاری ضعیف‌تر (Weaker Consistency) داشته باشیم البته نه اینکه سازگاری صفر (Zero Consistency) باشد بلکه نوع دیگری از سازگاری که می‌توانیم آن را به شکل سازگاری تدریجی (Eventual Consistency) مدل کنیم.
اگر بصورت مثلثی نمایش داده شود که اضلاع آن C و A و P باشند، می‌توانید هر زوج از این ویژگی‌ها را یکی از گوشه‌های این مثلث در نظر بگیرید. اگر به این گوشه‌ها نظر کنیم، یک پایگاه CA چه شکلی خواهد بود؟ چطور رفتار می‌کند؟
ذخیره‌گاه‌های CA به شما ویژگی‌های سازگاری و دسترس‌پذیری را می‌دهد. سئوال این است که اگر شبکه گسست پیدا کند چه رخ می‌دهد؟ از آنجاییکه شما فقط می‌توانید دو تا از ویژگی‌ها و نه هر سه را داشته باشید پاسخ این است که در این حالت عملیاتها اشتباه می‌شود. مثال از یک سیستم CA می‌تواند یک کامپیوتر منفرد باشد. اگر اوراکل را بر روی یک سرور اجرا کنیم، حداقل برای وقتی که برنامه بر روی همان ماشین اجرا شود، CA را داریم. اما اگر فرض کنید که گذرگاه حافظه (Memory Bus) داده‌ها را از دست بدهد، مثلاً یک عملیات حافظه انجام می‌دهید و شکست می‌خورد این به نوعی مانند گسست شبکه است و در نتیجه جواب اشتباهی می‌گیرید. این به نوعی یک راه حل CA است.
اما CA معنی نمی‌دهد زیرا ما اساساً داریم در مورد سیستم‌های توزیع‌شده صحبت می‌کنیم و این حوزه‌ی مورد بحث قضیه CAP است. بنابراین فکر نمی‌کنم که چیزی به نام سیستم CA وجود داشته باشد. ما درواقع بین سازگاری و دسترس‌پذیری انتخاب می‌کنیم و شاید یک کمی نوسان بین آن‌ها باشد. بنابراین ما در واقع بین CP و AP انتخاب می‌کنیم. گاهی افراد می‌گویند که در قضیه CAP ما ۳ ضلع داریم و دوتا از آن‌ها را انتخاب می‌کنیم اما من فکر می‌کنم که این اشتباه است. یا CP است یا AP چون شما P را خواهید داشت و به هرحال گسست شبکه را تحمل می‌کنید و در آن حال، نباید داده‌هایتان را خراب کنید.
بنابراین کمی در مورد این دو گزینه سیستم‌های نوع C صحبت کنید.
سیستم‌های C، سیستم‌های سازگار قوی (Strongly Consistent) هستند. اثبات قضیه CAP در مورد این صحبت می‌کند که توانایی انجام عملیات‌های تجزیه‌ناپذیر (Atomic) داشته باشیم و [سازگاری قوی] به این شکل است. در این سیستم‌ها می‌توانید کاری مثل افزایش دادن یک مقدار را بصورت تجزیه‌ناپذیر داشته باشید یا مثلاً بگویید اگر [مقدار فیلد] balance بزرگ‌تر از ۱۰ بود ۱۰ تا از آن کم شود و این عملیات تجزیه‌ناپذیر باشد. چون اگر دو تا عملیات داشته باشید که همزمان رخ می‌دهند و تسلسل (Serializability) آن‌ها را رسیدگی نکرده باشید ممکن است نتیجه اشتباه شود.
بنابراین دو مورد هستند که با سازگاری قوی می‌آیند. اصلش سازگاری در بکار بردن عملیات و تجزیه‌ناپذیر بودن آن عملیات است اما در عین حال در این مورد هم هست که داده‌ها تازه باشد و به صورت آنی سازگار شود. بنابراین وقتی سازگاری قوی ندارید، عموماً دو چیز را از دست می‌دهید. یکی قابلیت انجام عملیات‌های تجزیه‌ناپذیر است و دیگری این است که ممکن است داده‌های قدیمی را بخوانید یعنی ممکن است موقتاً داده‌های بیات (Stale Data) را بخوانید.
آیا می‌توانید مثال‌هایی از سیستم‌ها یا محصولاتی داشته باشید که در رده سیستم‌های کلاس C قرار می‌گیرند؟
بیشتر پایگاه داده‌های سنتی در کلاس C قرار می‌گیرند. آن‌ها از تراکنش پشتیبانی می‌کنند و اگر فردی عملیاتی را تثبیت (Commit) کند، و بعد شما آن را بخوانید تضمین شده است که تأثیر آن عملیات را ببینید.
در میان سیستم‌های NoSQL آیا سیستم‌هایی هستند که بر اساس کلاس C سازماندهی شده باشند؟
مسأله جالبی است چون فکر می‌کنم هر محصولی یک گرایش معماری (Architecture Bias) دارد. سازگاری تا حدی قابل تنظیم‌کاری (Tunable) است. مثلاً اگر MySQL را درنظر بگیرید، اگر آن را بر روی یک سرور منفرد استفاده کنید سازگار قوی است اما اگر رونوشت‌برداری ارشد/کارگزارِ (Master/Slave Replication) ناهمگام (Asynchronous) داشته باشید، و از روی سیستم کارگزار بخوانید، رفتار سازگار تدریجی (Eventually Consistent) خواهد داشت. بنابراین وابسته به این است که چطور محصول‌تان را برپا کرده باشید. اما سبک‌های مختلفی از محصولات وجود دارد. برخی از آن‌ها به شدت جانب سیستم‌های سازگار تدریجی را می‌گیرند و برخی دیگر هستند که به شدت جانب سیستم‌های سازگار قوی را می‌گیرند و برخی هم هستند که در میانه قرار دارند.
سیستم‌های کلاس A به چه شکلی هستند؟
ذخیره‌گاه‌های کلاس A در‌واقع تلاش می‌کنند که دسترس‌پذیری را بیشینه کنند. احتمالاً به این معنی است که جوری تنظیم می‌شوند که یک سیستمِ سازگار تدریجی باشند.
ما به اصطلاح سازگاری تدریجی که چندین بار استفاده کردید برخواهیم گشت. اما از مشکلی که مشاهده کرده‌اید و در پیِ آن کلاس A یا کلاس C را انتخاب کرده‌اید، می‌توانید مثالی بزنید؟
بله، بگذارید با کلاس A شروع کنیم. سیستم‌هایی که دسترس‌پذیری را بیشینه می‌کنند سازگار تدریجی هستند. مسأله جالب این است که افراد در مورد CAP زیاد صحبت می‌کنند اما برای استفاده از این سیستم‌های سازگار تدریجی چندین دلیل وجود دارد. یکی این است که از لحاظ نظری، هنگام گسست شبکه، به شما دسترس‌پذیری بالا (High Availability) را می‌دهد. اما خیلی از گسست‌های شبکه مواردی هستند که من آن‌ها را گسست‌های جزیی (Trivial) می‌نامم. مثلاً اگر ارتباط کل یک مرکز داده قطع شود و ۳ تا مرکز داده داشته باشید، این یک گسست جزیی است و می‌توانید به مرکز داده دیگری بازسپاری (Fail over) داشته باشید و از آن‌جا اجرا شوید چون همه کلاینت‌هایی که روی آن مرکز داده [قبلی] بوده‌اند قطع شده‌اند. اما گسست غیرجزیی این است که مثلاً ساحل غربی آمریکا، بتواند با ساحل غربی صحبت کند و ساحل شرقی بتواند با ساحل شرقی صحبت کند اما این دو نتوانند با هم صحبت کنند. این یک گسست غیرجزیی است که سخت‌‌تر است و اگر یک سیستم کلاس A و سازگاری تدریجی داشته باشید خوشحال خواهید بود. اما اگر گسست جزئی داشته باشید می‌توانید با هرکدام از مدل‌ها، مسأله را رسیدگی کنید.
خیلی از گسست‌ها، جزیی هستند و مثلاً کل یک قفسه (Rack) را از دست می‌دهید. این به ما می‌گوید که جنبه دسترس‌پذیری که در سیستم‌های سازگار تدریجی و کلاس A مطرح می‌شود مقداری بیش از اندازه وزن گرفته است. با این حال، مزیت بزرگی در این است که در پیکربندی‌‌های دارای چندین مرکز داده، خواندن و نوشتن‌های با تأخیر کم داشته باشیم که [این سیستم‌ها] چنین امکانی را به شما می‌دهند. چون لزوماً مجبور نیستید صبر کنید تا داده‌ها از پیش به دیگر مراکز داده‌ها گذر داده شوند. بنابراین تأخیر (Latency) در واقع جنبه کلیدی معادله‌ای است که CAP به هیچ وجه آن را پوشش نمی‌دهد. من فکر می‌کنم که سازگاری، دسترس‌پذیری و تأخیر، متغیرهای کلیدی هستند.
پیش از آنکه بخواهیم بگوییم که جنبش NoSQL چه می‌گوید، با این فضای همه انواع تصمیمات طراحی روبرو هستیم و نیاز داریم که برای حل مسأله، همه فضا را در نظر بگیریم اما اگر پیش‌فرضمان را پایگاه رابطه‌ای قرار داده باشیم شاید از مزیت [در نظر گرفتن ویژگی‌های خاص] مسأله‌ای که تلاش در حلش داریم بهره نبریم.
من اینطور به آن فکر می‌کنم که همانطور که مایکل استون بریکر گفته است: دوره‌ای که یک اندازه به همه بخورد به پایان رسیده است. (اشاره به این مقاله است -مترجم) امروزه می‌توانیم برخی اختصاصی‌سازی‌هایی را در پایگاه داده ببینیم. نمی‌توان از یک ابزار برای همه چیز استفاده کرد؛ مثلاً نمی‌شود MongoDB را برای همه کارها استفاده کرد. اما برای هر کاری ابزار درستش وجود دارد که بسته به اینکه چه کاری بخواهید بکنید این ابزار متفاوت است.
در زمینه قضیه CAP برای MongoDB چه تصمیماتی گرفتید؟
MongoDB بیشتر در کلاس C است و پیکربندی پیش‌فرض آن، سازگار قوی است. من NoSQL را اینطور تعریف می‌کنم که همه راه‌حل‌ها را دارد اما الحاق و تراکنش‌های پیچیده را انجام نمی‌دهد چون اگر این دو را کنار بگذارید، مقیاس‌پذیری افقی کاملاً ممکن می‌شود. بنابراین ما این دو کار را نمی‌کنیم. اما به غیر از آن، واقعاً تلاش می‌کنیم تا هر قدر که بتوانیم ویژگی‌های پایگاه داده‌های سنتی را حفظ کنیم. بنابراین آنچه برای دستیابی به مقیاس‌پذیری افقی مجبور بوده‌ایم را کنار گذاشته‌ایم اما همه چیزهای دیگر را نگه داشته‌ایم. بنابراین از یک نظر، خیلی سنتی است. ما شاخص‌های ثانویه (Secondary Index) داریم، از پرس‌وجوهای موردی (Ad-hoc Query) پشتیبانی می‌کنیم، مرتب‌سازی را پشتیبانی می‌کنیم و ... . بنابراین خیلی از این چیزها که از یک پایگاه داده انتظار دارید، وجود دارد. اگر به برخی محصولات دیگر بنگرید، شاید شگفت‌آور نباشد که آن‌ها رهیافت‌های خیلی متفاوتی را در برای این مسأله داشته‌اند. اما رهیافت ما، بیشتر در اردوگاه سازگاری قوی قرار می‌گیرد. بنابراین در MongoDB می‌توانید عملیات تجزیه‌ناپذیر داشته باشید؛ ما اجازه می‌دهیم که این کار را در یک شیء تک داده‌ای انجام دهید. بنابراین ما مفهوم تراکنش‌های پیچیده را نداریم اما مفهوم تراکنش‌های ساده را عرضه می‌کنیم. ما می‌توانیم این کار را بکنیم و همچنان مقیاس‌پذیری افقی هم داشته باشیم. اما همین داشتن قابلیت تجزیه‌ناپذیری نوع ساده، اجازه انجام خیلی کاربردها را برای‌تان فراهم می‌کند. روشن است که جایی پیش می‌آید که به بیش از آن نیاز داشته باشید اما جایی هم هست که اصلاً به هیچ شکلی از تجزیه‌ناپذیری نیاز ندارید و در این وسط مواردی هم هست که ما آن را پوشش می‌دهیم.
افراد با MongoDB چه می‌کنند؟
خیلی کارها می‌کنند. فکر می‌کنم بزرگترین کاربرد کل این فضای جدید NoSQL در ساختن زیرساخت‌های وب و استفاده از این محصولات به عنوان ذخیره‌گاه عملیاتی زیرساخت‌های وب است. ذخیره کردن محتوای یک وب سایت، اطلاعات نشست‌های کاربری (User Session)، اطلاعات پروفایلی، لاگ زدن، شمارنده‌های برخط سنجش کارایی، این‌ها همگی کاربردهای رایج این سیستم‌ها هستند. ذخیره‌سازی تصاویر و ویدئوها [هم هست]. بیشترِ مسائل برخط ذخیره داده‌ها که خیلی تراکنشی نباشند، کاملاً با آن‌جور می‌شود. اما فکر می‌کنم با گزارش‌گیری، خیلی هم‌راستا نیست البته حتماً با این سیستم‌ها هم، می‌توانید گزارش‌‌گیری داشته باشید اما سئوال این است که آیا بهترین ابزار این کار است؟ و گاهی اینطور نیست چون راه حل‌های گزارش‌گیری خیلی خوبی در فضای رابطه‌ای و SQL وجود دارد. همینطور جاهایی که مقیاس با سرعت بالا زیاد می‌شود، می‌بینیم که افراد آن را دوست دارند. برای مسائلی که توسعه سریع می‌خواهند آن را دوست دارند. مثلاً در MongoDB که یک پایگاه JSON است اساساً شِمای پویا (Dynamic Schema) دارد. بنابراین می‌توانید اشیاء JSON را در یک مجموعه (Collection) قرار دهید (در MongoDB، مجموعه، همان مفهوم معادل جدول در پایگاه‌های رابطه‌ای است -مترجم) و اگر بخواهید که فیلد جدیدی که در اشیاء دیگر وجود ندارد را در یکی از این اشیاء قرار دهید، مشکلی نیست و مجبور نیستید که برای آن، فرمانی مشابه Alter table را اجرا کنید. بنابراین کارهای مربوط به مهاجرت دادن شِما، به شدت کاهش می‌یابد و این با توسعه چابک خیلی تطبیق دارد؛ اگر هر روزه انتشار (Release) داشته باشید، نمی‌خواهید اسکریپت مهاجرت دادن شِما را هرروزه انجام دهید. بنابراین خیلی خوب با آن جور می‌شود.
آیا در یک برنامه تحت وب یا تک برنامه مربوط به یک کسب و کار، خیلی بیشتر [از گذشته] این را می‌بیینید که افراد چندین راه‌حل ذخیره داده را بر اساس نیاز سرویس‌های خاص، با هم ترکیب کنند؟
بله. فکر می‌کنم سازمان‌های بزرگ، از چندین محصول استفاده خواهند کرد. اگر من مدیرارشد IT در یکی از آن ۱۰۰۰ شرکت ثروتمند باشم، قطعاً اوراکل را برای برخی کارها و برخی مسائل از نوع OLTP می‌خواهم. مسائل OLTP خیلی تراکنشی هستند. همینطور از راه‌های NoSQL ای مانند MongoDB برای خیلی از مسائلی استفاده خواهم کرد که به نوشتن و خواندن‌های سریع و بلادرنگ برای ذخیره‌سازی برخط نیاز است و نیاز به انعطاف بیشتری بر روی شِما و داده هست و واقعاً افزایش مقیاس آن سریع است. برای اینکه توسعه راحت‌تر شود [از آن استفاده خواهم کرد]. به علاوه چیزهایی مانند Greenplum و Aster Data وVertica را هم بکار می‌‌گیرم و از آن‌ها برای انبار داده و کارهای BI استفاده می‌کنم. اما گفته باشم که اگر یک سازمان کوچک باشم، احتمالاً از همه این چیزها استفاده نمی‌کنم. امروزه ما کاربران زیادی داریم که وب‌سایت می‌سازند و صددرصدِ داده‌های‌شان در Mongo ذخیره شده است و این تنها چیزی است که استفاده می‌کنند. این حتی تصاویر و ویدئوها را هم شامل می‌شود وحتی آن‌ها را در فایل‌سیستم ذخیره نمی‌کنند که به نوعی جالب است. اما فکر می‌کنم اگر شرکت بزرگ‌تر شود، شما از بازه وسیع‌تری از راه‌حل‌ها استفاده خواهید نمود چون به مقیاسی رسیده‌اید که منطقی است که کمی تخصصی‌تر کار کنید.
ما کمی در مورد ضعیف کردن سازگاری صحبت کردیم. شما مقالات جالبی در مورد محدوده مدل‌های سازگاری در وبلاگ خود دارید. به نظرم، هرکسی باید به وبلاگ MongoDB برود و مجموعه ۶ پستی که در مورد سازگاری در آن هست را ببیند. در آنجا نمودارهایی هست که می‌توانید ببینید. می‌خواهم مرور آن را از سازگارترین مدل آغاز کنیم و در مورد هریک توضیح مختصری بدهیم. [اولین مورد] تراکنش‌های چندموجودیتی است که فکر می‌کنم بدانم چیست.
بله، سازگاری قوی با تراکنش‌های کامل. مثلاً شیء بدهکاری A و بستانکاری B را دارید و این کار را بصورت تجزیه‌ناپذیر در یک تراکنش انجام می‌دهید. این همان تراکنش کلاسیک پایگاه داده است که با چیزهایی مانند اوراکل یا با InnoDB در MySQL انجام می‌دهید.
و بعد، مدل سازگاری قوی در سطح یک موجودیت را دارید؟
درسته. این همان چیزی است که می‌توانید با MongoDB انجام دهید. در MongoDB شما می‌توانید بدهکاری A و بستانکاری B را [بصورت تراکنش تجزیه‌ناپذیر] انجام دهید اگر و تنها اگر هر دو در یک شیء یکسان باشند. اگر هر دو در یک شیء JSON یکسان باشند می‌توانید آن را بصورت تجزیه‌ناپذیر انجام دهید اما اگر در اشیاء داده مختلفی باشند، بحث چندموجودیتی می‌شود و نمی‌توانید این کار را بکنید.
و مدل سازگاری آنی (Immediate Consistency) چیست؟
این جایی است که اگر کسی بخواهد چیزی بنویسد، ما تضمین می‌کنیم که نتیجه آن نوشتن بلافاصله دیده شود. با این حال، این با تجزیه‌ناپذیر بودن متفاوت است چون می‌توان سازگار آنی بود اما تجزیه‌ناپذیر نبود.
و مدل نوشته خودتان را بخوانید (Read Your Own Write) چطور؟
این یک فرم ضعیف‌تر سازگاری است که می‌گوید ممکن است چندی طول بکشد که یک نوشتن، توسط همه قابل خواندن باشد اما اگر شما کسی باشید که نوشتن را انجام داده‌اید، تضمین می‌شوید که شما آن را ببینید. خیلی مفید است که این مفهوم را در سیستم‌های سازگار تدریجی داشته باشیم که کمک کند برنامه‌های صحیحی بسازیم.
یعنی اگر شما کلاینت باشید و چیزی بنویسید، مجبور نیستید که صبر کنید تا نوشتن خودتان در نهایت سازگار شود؟
درسته. مثال خوبش این است که اگر من به سایت شبکه اجتماعی خودم بروم و تصویر پروفایل خود را عوض کنم اگر چند ثانیه طول بکشد که به دیگر کاربران نمایش داده شود مشکلی نیست اما اگر وقتی من OK را می‌زنم و آن را اعمال می‌کنم بعد به صفحه اصلی‌ام برگردم و تصویر قدیمی‌ام را ببینم خیلی سردرگم می‌شوم. بنابراین مدل «نوشته خودتان را بخوانید»، از سردرگمی جلوگیری می‌کند. اشکالی ندارد که دیگر افراد تصویر قدیمی را ببینند چون آن‌ها خبر ندارند که بروزرسانی رخ داده است و در این مورد، آن‌ها را سردرگم نمی‌کند. اما نکته جالب در مورد مدل «نوشته خودتان را بخوانید» این است که محدوده شُمایی که قرار است نوشته خودتان را بخوانید تا کجاست؟ در واقع، یک کاربر وب‌سایت است و بنابراین یک درخواست منفرد HTTP به سرور برنامه نیست. در‌واقع در این درخواست بعدی که از همان کاربر است می‌خواهیم نوشته خودش را بخوانیم. پیاده‌سازی این گاهی سخت است چون ترازگرهای بار (Load Balancer) ممکن است درخواست بعدی را به ماشین دیگری بفرستند.
آیا MongoDB چنین سطحی از سازگاری را برآورده می‌کند؟
اگر سازگاری قوی داشته باشید، به شکل خودکار، سازگاری «نوشته خودتان را بخوانید» را هم خواهید داشت و هم به شکل خودکار، سازگاری آنی را خواهید داشت. بنابراین در این جا تا حدی سلسله‌مراتب وجود دارد. البته چند حالت خاص وجود دارد که ممکن است یکی را داشته اما دیگری را نداشته باشید.
سازگاری خواندن یکنواخت (Monotonic Read) چطور؟
سازگاری خواندن یکنواخت، یک سیستم سازگار تدریجی است که یک ویژگی اضافی دارد که برای یک خواننده، اگر داده‌ای را ببینند، هیچ‌گاه نسخه قدیمی‌تری از آن داده را نخواهند دید. در شکل خالص سازگاری تدریجی، ممکن است که اینطور نباشد. مثلاً فرض کنید که یک موجودیت داده X داریم و فرض کنید که کسی مقدار ۱ را در آن نوشته و یک ثانیه بعد، ۲ را می‌نویسند و یک ثانیه بعد، مقدار ۳ را می‌نویسند و یک ثانیه بعد مقدار ۴ را می‌نویسند. اگر شکل خالص سازگاری تدریجی را داشته باشید ممکن است از آن ۳ را بخوانید، بعد ۱ را بخوانید و بعد ۲ و مجدد ۲ و در انتها ۴ را بخوانید و بعد برای همیشه ۴ را بخوانید چون در این سازگاری به تدریج به آن می‌رسید. اما به این شکل، مقادیر را با ترتیب عجیبی دریافت می‌کنیم که می‌تواند از لحاظ مفهومی، گیج‌کننده باشد که چه دارد رخ می‌دهد. اما در سازگاری خواندن یکنواخت، اگر این نوشتن‌ها در X با ترتیب ۱، ۲، ۳ و ۴ باشد ممکن است من به شکل آنی ۴ را نبینم اما اگر ۲ را دیدم، دیگر چیزی قبل از ۲ را نخواهم دید. سازگاری خواندن یکنواخت به این معناست. برای برنامه‌نویس از نظر شهودی این حالت نسبت به نوع خالص سازگاری تدریجی، خیلی منطقی‌تر است. فرضاً اگر از MySQL استفاده کنید و رونوشت‌برداری ارشد/کارگزار (Master/Slave Replication) داشته باشید و ۱۰ ماشین کارگزار داشته باشید که بصورت ناهمگام بر روی ارشد، رونوشت‌برداری می‌کنند؛ در این حال اگر از روی یک کارگزار بخوانید، سازگاری تدریجی را خواهید داشت. شاید به عنوان یک کلاینت تنها از روی یک کارگزار تصادفی می‌خوانید چون تلاش می‌کنید که بار را توزیع کنید اما هرکدام از این کارگزارها در اعمال لاگ‌هایی که به شکل ناهمگام از ارشد می‌گیرد، ممکن است در نقطه متفاوتی قرار گرفته باشد. بنابراین در این شکل پیکربندی، می‌توانید نتایجی را بگیرید که سازگاری خواندن یکنواخت نداشته باشد.
به عنوان یک معمار نیاز دارم که در این مورد فکر کنم که برای یک برنامه، چه مقدار سازگاری نیاز دارم. و هزینه هر افزایشی در سازگاری را با سخت‌تر کردن سناریوهای شکست می‌پردازم یعنی با افزایش دادن احتمال زمان بیشترِ پایین بودن در برخی شرایط شکست.
درسته. وقتی سازگاری‌های بیشتری می‌خواهید از لحاظ نظری، به نسبت کمی از دسترس‌پذیری را از دست می‌دهید و همینطور، در پیکربندی‌های چند مرکز داده‌ای، میزان تأخیر (Latency) هم بدتر می‌شود اما در عوض، مفاهیم روشن‌تر و مشهودتری برای پایگاه داده بدست می‌آورید. بنابراین، این یک مصالحه (Trade-off) است. فکر می‌کنم می‌توانید با سازگاری تدریجی، خیلی از مسائل را حل کنید اما مفاهیمش غافلگیرکننده است و واقعاً نیاز است که توسعه‌دهنده فکر کند به چه چیزی نیاز دارد: آیا سازگاری تدریجی کافیست یا شاید سازگاری تدریجی با خواندن‌های یکنواخت مسأله را بتواند حل کند و یا شاید سازگاری «نوشته خودتان را بخوانید» خوب باشد و یا شاید به بیش از آن نیاز داشته باشم، شاید به سازگاری آنی نیاز داشته باشم، یا شاید به تجزیه‌ناپذیری نیاز داشته باشم و یا شاید به تراکنش کامل نیاز داشته باشم. بنابراین هرچه سازگاری بیشتر باشد، ما برنامه‌نویس‌ها می‌توانیم تنبل‌تر باشیم. در غیراینصورت، باید سخت‌تر کار کنید تا آن را بسازید. من فکر می‌کنم همه این مدل‌ها، مفید هستند. با این وجود، دوست دارم پیش‌فرض، سازگاری قوی باشد چون کم‌ترین مفاهیم غافلگیر کننده را دارد. وقتی به سمت سازگاری‌های ضعیف‌تر می‌رویم، باید واقعاً خود را آماده کنیم و بیشتر فکر کنیم تا اطمینان حاصل کنیم که کار را به درستی انجام می‌دهیم.
وقتی می‌گویید برنامه‌نویس باید سخت‌تر کار کند منظورتان چیست؟
در‌واقع به چند شکل است. یکی اینکه باید دقت کنید که طراحی‌تان صحیح باشد. مثلاً اگر بگویید که خیلی خوب، از سازگاری تدریجی استفاده می‌کنم فرضاً اگر از Amazon SimpleDB در حالت سازگاری تدریجی استفاده کنید -که در‌واقع الان سازگاری قابل تنظیم دارد اما پیش‌فرضش این است- در اینصورت اگر اجازه دهید که فردی تصویر پروفایلش را بارگذاری کند و بعد به صفحه اصلی‌اش برگردد و تصویر قدیمی را ببیند، گیج می‌شود. گیج کردن کاربر، بد است و به این شکل می‌تواند یک خطای طراحی باشد. اما برنامه‌نویس در موردش فکر می‌کند و فرض می‌کند که می‌تواند ایرادی نداشته باشد. اینکه در سازگاری تدریجی، کاربر گیج می‌شود کمی دردآور است اما دنیا به آخر نمی‌رسد. اما مواردی هم هست که اهمیت بیشتری دارد. یک مثال خوبش این است که فرضاً سایتی به اسم Flickr داشته باشم و انتخاب کنم که چه کسانی تصاویرم را استفاده کنند و فهرستی از آن افراد داشته باشم. حال فرض کنید که داخل می‌شوم و فردی -مثلاً دوست دخترم- را از لیست افرادی که از تصاویرم استفاده می‌کنند را پاک می‌کنم و بعد تصویر جدیدی را پُست می‌کنم که نمی‌خواهم او ببیند. اما اگر سیستم سازگار تدریجی باشد، احتمال بزرگ‌تر از صفری وجود دارد که تصویر را ببیند که می‌تواند مشکل عظیمی باشد! این سناریویی است که قطعاً به سازگاری با درجه بیشتری نیاز دارید تا مسأله را به درستی حل کنید. این آنقدر هم بد نیست که سازگاری تدریجی داشته باشیم اما مسأله این است که برای آن مورد خاص، نباید از آن استفاده کنیم. در واقع، این کار ذهنی توسعه‌دهنده را می‌طلبد که بفهمد در فلان مسأله خاص اشکالی ندارد.
مثلاً اگر وبلاگی داشته باشم و افراد نظر بدهند و آن‌ نظر‌ها را خارج از ترتیبش ببینند و دیرتر نمایش داده شود، شاید مشکل بزرگی نباشد.
درسته. فکر می‌کنم در وبلاگ، سازگاری خواندن یکنواخت، خیلی خوب باشد. چون بد است اگر صفحه را ریفرش کنم و نظرها ناپدید شوند. این خیلی گیجم می‌کند. اما اگر [سازگاری خواندن یکنواخت فراهم باشد و] نظر بدهید و یک ثانیه بعد از آن صفحه را دوباره بارگذاری کنم و آن را نبینم، اشکالی ندارد چون اگر دو ثانیه قبل هم صفحه را بارگذاری کرده بودم باز هم آن را نمی‌دیدم. با این حال، احتمالاً سازگاری «نوشته خودتان را بخوانید» را هم می‌خواهید چون اگر نظری بدهم و برگردم و نظر خود را نبینم، گیج می‌شوم. بنابراین فکر می‌کنم در یک سیستم فراهم‌کننده وبلاگ، سازگاری تدریجی کار می‌کند اما چیزی که واقعاً می‌خواهم سازگاری خواندن یکنواخت و سازگاری «نوشته خودتان را بخوانید» است.
وقتی می‌گویید که برنامه‌نویس باید سخت‌تر کار کند منظورتان این است که باید سناریوهای بیشتری را در نظر بگیرد که اگر رخ داد چه می‌شود.
بله. اگرفرضاً نظرها را در پایگاه داده اوراکل قرار داده بودید، مجبور نبودید به هیچکدام از این چیزها که گفتم فکر کنید و نتایج غیرمنتظره دریافت نمی‌کردید.
این راه‌حل‌های NoSQL از دیدگاه مدل ذخیره‌سازی آن‌ها چطور طبقه‌بندی می‌شوند؟ مدل‌های ذخیره‌سازی اصلی کدامند؟
فکر می‌کنم این موضوع مهمی است که تا الان توضیح داده نشده است. هیچکدام از راه‌حل‌ها، مدل داده رابطه‌ای ندارند چون می‌خواهیم مقیاس‌پذیری افقی ساده شود. با رابطه‌ها، داشتن مقیاس‌پذیری افقی خیلی سخت است. بنابراین آنچه همه این راه‌حل‌های NoSQL می‌گویند این است که بگذار رابطه‌ای نباشیم تا مسأله را ساده‌تر کند و بتوانیم آن را حل کنیم. این همان کاری است که گوگل با BigTable کرده، آمازون با Dynamo کرده و LinkedIn با Voldemort کرده است. همه آن‌ها می‌گویند که ذخیره‌گاه‌های غیررابطه‌ای هستند.
بنابراین، سئوال اینجاست که وقتی مدل داده‌ها رابطه‌ای نیست، پس مدل داده چیست؟ من فکر نمی‌کنم هنوز به این موضوع به مقدار کافی توجه شده باشد. چندین انتخاب وجود دارد. یکی این است که تنها یک ذخیره‌گاه ساده کلید/مقدار باشیم. Dynamo در آمازون به همین شکل است. بنابراین مدلی که آنجا وجود دارد این است که [نگاشتی] از کلید اصلی به مقدار باشد که مقدارش، تنها یک داده باینری (Blob) مبهم است که نمی‌توانیم به داخلش دسترسی یابیم. مثلاً Memcached یک ذخیره‌گاه کلید/مقدار است. البته از نوع مانای آن (Persistent) نیست اما یک ذخیره‌گاه کلید/مقدار است. بنابراین این مدل کلید/مقدار است که با آن کار آغاز شد و ساده‌ترین کاری است که می‌توانید بکنید. چیز واقعاً عالی در آن این است که آنقدر ساده است که مقیاس‌پذیر کردن آن و سرعت بخشیدن به آن بسیار ساده است. به همین خاطر Memcached سریعتر از هر چیز دیگری است. اما این محدودیت را دارد که نمی‌تواند کار خیلی زیادی بکند. تنها یک مدل کلید/مقدار و فقط مخصوص همین است.
مدل داده BigTable گزینه دیگر یا رده‌ای از مدل‌های دیگر است که در آن جداول چندبعدی را دارید که انعطاف‌هایی در ستون‌ها دارند؛ این نوعی ویژگی است که در آن‌ها وجود دارد. این هم یک مدل داده است.
مدل داده دیگر، موردی است که آن را پایگاه‌های سندگرا (Documented Oriented) می‌خوانید. منظور ما از سند، سندهای متنی نیست. فرضاً به سند‌های XML ای فکر کنید که ساختاری دارند. در واقع، روند کار به این شکل پیش می‌رود که برای این اسناد، JSON برای همه استاندارد شده است. بنابراین در واقع، در راه‌حل‌های سندگرا، داده‌های شئ‌‌مانند و به طورخاص با فرمت JSON را در پایگاه داده ذخیره می‌کنیم.
با آنکه برای مدت طولانی، پایگاه‌های XMLای وجود داشته‌اند، هنوز به عنوان یک نوع دیگر از اسناد [در پایگاه‌های سندگرا] قرار نگرفته‌اند. من حدس می‌زنم که پایگاه‌های JSON همین حالا، بیشتر از پایگاه‌های XML ای مستقر شده‌اند و خیلی موفق‌تر بوده‌اند. آیا با این موافقید؟
موافقم.
و چرا اینطور است؟
فکر می‌‌کنم مربوط به زمان و ارزش پیشنهادی آن است. وقتی که پایگاه‌های داده XML ای آمدند، فکر می‌‌کنم بخشی از گزاره‌ پیشنهادی آن این بود که یک روش ساده برای ذخیره‌سازی داده‌های شبه‌ساختیافته است و اگر وب‌سرویس‌های زیادی با فرمت XML می‌داشتید، روش ساده‌ای برای ذخیره کردن XML بود و بنابراین چیز خوبی‌ برایتان بود. اما فکر می‌‌کنم آنچه افراد در عمل فهمیدند این است که آن را به برنامه‌‌تان اضافه می‌کنید اما بهرحال برنامه‌تان به پایگاه‌های رابطه‌ای گره خورده است و به استفاده از آن هم ادامه می‌دهید. بنابراین آن‌ها عموماً، مقیاس‌پذیری افقی که در واقع محرک بزرگ کار است را برای شما فراهم نمی‌کنند.
پایگاه‌های رابطه‌ای آنچنان بالغ هستند که همه آن را می‌شناسند و همه آموزش آن را دیده‌اند. بنابراین فراتر رفتن از آن خیلی سخت‌تر است. برای این منظور، به یک ارزش پیشنهادی بزرگ نیاز است و بدست آوردن مقیاس‌پذیری افقی، یک چیزی است که به حد کافی بزرگ هست که افراد را به تکان آورد. فکر می‌‌کنم در مورد پایگاه‌های XML این مسئله وجود نداشت. همچنین XML خسته‌کننده است و خواندنش راحت نیست اما خواندن JSON برای برنامه‌نویس‌ها راحت است و مانند کد است با این تفاوت که بخش داده آن است. ما همانند XML برای JSON هم استاندارد و RFC داریم و هر توسعه‌دهنده وبی آن را می‌شناسد چون برای توسعه برنامه‌های تحت وب باید آن را بشناسید. یک فرمت خیلی راحتِ مستقل از زبان برای داده‌های شیءمانند است.
شما می‌گویید که پایگاه‌های سند‌گرای JSON از نبود هر چیزی مانند DTD یا شِمای XML، که برای اعتبارسنجی ورودی‌ها باشد، رنج می‌برند؟
سئوال خوبی است. البته با این پایگاه‌های JSON امکانپذیر است که قبل از آنکه داده‌ها را تغییر دهید، نوعی بررسی‌ شِما هم اضافه کنید. بنابراین اگر بخواهید می‌توانید شِماهای سفت و سخت برایش بسازید. در روزهای اولیه Mongo من فکر می‌کردم که یک موقعی این کار را خواهیم کرد اما نکته جالب این بود که افراد این را از ما نخواستند. بنابراین فکر می‌کردم که تا حالا انجامش داده باشیم اما نکردیم چون در عمل، مشکلی با داده‌های نویزی نداشتیم. در MongoDB شما مجموعه‌هایی از سندهای JSON دارید. هرچند که مجموعه‌های JSON چنین چیزی را الزام نمی‌کنند اما خیلی رایج است که در یک مجموعه، فیلدهای کاملاً همگنی برای همگی اشیاء JSON داشته باشید. آنگاه چیزی که خیلی خوب است این است که می‌توانید یک فیلد جدید اضافه کنید، می‌توانید آن را به یک شئ و نه بقیه اضافه کنید و مجبور نیستید که دستور Alter Table را اجرا کنید که انجام دادن آن، در برخی مقیاس‌ها بهرحال، ناممکن است. این‌ها خیلی خوب است اما این روند مشهود است که درواقع داده‌ها به خودی خود، تمیز می‌مانند.
تشبیه خوبی که در این مورد می‌توان داشت این است که مانند زبان‌های برنامه‌نویسی نوع پویا (Dynamic Type) است. در یک زبان برنامه‌نویسی نوع پویا وقتی انواع با هم تطابق ندارد، خیلی از خطاها، ممکن است در زمان اجرا رخ دهد. وقتی من بیست و چندسال پیش، این را شنیدم اولین واکنشی که داشتم این بود که این خیلی ترسناک به نظر می‌رسد. اما مشخص شد که امکان این کار هست -که کار توسعه را ساده‌تر می‌کند- اما در عین حال، می‌توان نوع ایستا (Static) هم داشت. MongoDB به زبان C++ نوشته شده است؛ من نوع‌های ایستایی که آنجا وجود دارد را دوست دارم اما درعین حال، می‌توانم بفهمم که چرا فردی از زبان‌هایی مانند Lisp یا Ruby که نوع پویا هستند استفاده می‌کند. بنابراین فکر می‌کنم کم‌وبیش چنین شباهتی وجود دارد که وقتی یک نوع پویاتر را در پایگاه داده داریم، مزایایی دارد. به عنوان یک مثال خوب از آن، فرض کنید که برای اشیاءتان ساختار سلسله‌مراتبی دارید، یعنی یک کلاس پایه و چند زیرکلاس دارید؛ در یک پایگاه JSON، اگر یک شِمای دارای نوع نداشته باشم، خیلی ساده است که همه این اشیائی که از کلاس پایه ارث برده‌اند را در یک مجموعه قرار دهم چون این قضیه که زیرکلاس B فیلد اضافه‌ای دارد مشکلی ایجاد نخواهد کرد و همه به خوبی و خوشی آنجا می‌نشینند. بنابراین برخی نگاشت‌های داده‌ای را کاملاً ساده می‌کند.
امروز صبح یک سخنرانی در مورد طراحی شِما در MongoDB داشتید. در مورد انتخابِ بین پیوند برقرار کردن (Linking) یا تعبیه کردن (Embedding) بگویید.
پیوند برقرار کردن مانند کلیدهای خارجی در پایگاه داده‌های سنتی هستند که رکورد A را فرضاً به رکورد B در جایی دیگر از پایگاه داده، اشاره می‌داد یا مثلاً در پایگاه‌های شیءگرا، پیوندهایی بین اشیاء دارید. در آنجا، تعداد خیلی زیادی پیوند وجود دارد و در پایگاه‌های شیءگرای سبک قدیم، گرافی از پیوند‌های بین اشیاء دارید که مانا شده است. اما رهیافتی که در این پایگاه‌های JSON وجود دارد از اساس متفاوت است به این معنی که می‌توانید پیوند برقرار کنید اما اگر بخواهید پیوند دهید باید اینکار را خودتان در سمت کلاینت با فرستادن یک درخواست اضافی به سرور، انجام دهید. اگر بخواهم کاری را انجام دهم که نیاز به پیمایش یک یا دو پیوند داشته باشد و در همان شبکه LAN ای باشم که سرور پایگاه داده قرار گرفته است و چرخ زدن به پایگاه داده در حد چند نانوثانیه باشد، مسأله‌ای نیست اما اگر نیاز داشته باشم که یک هزار پیوند را پیمایش کنم، کار کُند می‌شود و بنابراین چنین کاری نخواهم کرد. مقدار کمش اشکال ندارد و کمک می‌کند که مسائل‌مان را حل کنیم اما زیادش بد است. بنابراین در عوضِ پیوند برقرار کردن، آن را تعبیه می‌کنیم یعنی سند‌های JSON ای می‌سازیم که به نسبت غنی هستند که یک میزان منطقی از داخل کردن (Nesting) اشیاء در یکدیگر را داراست.
شما توضیح داد‌ه‌اید که از الحاق اجتناب می‌کنید تا به سادگی، مقیاس‌پذیری افقی را داشته باشید. پس می‌گویید که این الحاق‌هایی که افراد در پایگاه‌های سنتی انجام می‌دهند ناشی از این قضیه است که آن‌ها داده‌های‌شان را نرمال کرده‌اند اما [در MongoDB] شاید نرمال کردن داده‌ها، طبیعی‌ترین روش کار نیست.
بخشی از آن همین است و بخش دیگر هم این دلیل است که رابطه و اتصال بین موجودیت‌ها، [همچنان] معتبر است. اما درست می‌گویید: فرضاً اگر یک شیء از نوع «سفارش» داشته و یک جدول دیگر از نوع «قلم سفارش‌‌شده» داشته باشید و آن دو را الحاق کنید، دارید چیزی را دوباره با هم ترکیب می‌کنید که از لحاظ مفهومی، یک چیز بوده است؛ ما آن‌ها را در پایگاه داده از هم باز کرده‌ایم. ما فقط برای اینکه به شکل کارایی با مدل رابطه‌ای جور شود، آن‌ها را به شکلی افراطی تکه‌تکه کرده‌ایم. این مثالی از الحاقی است که به نوعی مصنوعی است. اما مثلاً وقتی می‌گویید که «مجموع کل مقدار دلارهایی که فلان مشتری پرداخته است را بده» و برای آن نیاز به الحاق کردن جدول سفارش‌ها داریم، در این‌ مورد، خیلی منطقی است.
امروز صبح، یکی از سخنران‌های کنفرانس گفت که من نمی‌خواهم قبل از آنکه داده‌ام را در پایگاه داده قرار دهم یک فیل روی آن بنشیند!
:-) بله، این خنده دار است. وقتی از یک ذخیره‌گاه JSON استفاده می‌کنید، قطعاً خیلی از این ناسازگاری‌های بین اشیاء و جداول رابطه‌ای، از بین می‌رود. مطلب جالب این است که باز هم طراحی شِما را انجام خواهید داد و همچنان روال خودش را دارد. در Mongo، ما همچنان مجموعه‌ها (Collection) و شاخص‌ها (Index) را تعریف می‌کنیم و همچنان فیلدهایی که در این اشیاء قرار می‌گیرند را انتخاب می‌کنیم. بنابراین اینکه چه ساختاری به داده‌های‌مان بدهیم، همچنان روال خودش را دارد. البته با پایگاه‌های شیءگرا -که در آن‌ها برنامه‌، ساختار داده‌هایی که مانا خواهند شد را تعریف می‌کند- کاملاً متفاوت است. چون فکر می‌کنم ذکر این مطلب اهمیت دارد که ما می‌خواهیم داده‌ها را با قالبی در پایگاه داده قرار دهیم، که برای خواننده‌ای که کد برنامه را نمی‌شناسد، قابل درک باشد.
آیا زبان‌های برنامه‌نویسی یا فریم‌ورک‌های وب محبوب خیلی زیادی هستند که به مانند آنچه که در پایگاه‌های رابطه‌ای خیلی مرسوم است، نوعی لایه نگاشت‌گر داشته باشند که داده‌ها را داخل و خارج کند.
بله، فریم‌ورک‌های زیادی وجود دارد مثلاً MongoMapper در Ruby هست که چیزی مانند ActiveRecord است. این‌ها هستند با این وجود، این لایه نگاشت، [به نسبت نگاشت‌گر‌هایی که برای پایگاه‌های رابطه‌ای وجود دارد]، ده برابر باریک‌تر است. بنابراین همچنان نگاشت را می‌کنیم و نوعی فریم‌ورک مدل کردن و از اینجور چیزها داریم اما پیچیدگی این لایه‌های نگاشت‌گر، به شکل قابل ملاحظه‌ای کاهش یافته است چون چیزهایی که داریم بین آن‌ها نگاشت انجام می‌دهیم خودشان خیلی به هم نزدیک هستند.
همکار شما، ریچارد کریتر ارائه‌ای داشت که می‌گفت شما می‌توانید این ذخیره‌گاه‌های NoSQL را براساس یک محور دیگر هم دسته‌بندی کنید و آن این است که آن‌ها، چطور داده‌ها را در یک توری از خوشه‌ها (Grid of Clusters) پخش می‌کنند. مدل‌های نماینده اصلی در این محور کدا‌مند؟
بله، این درست است. در این سیستم‌ها، راه‌های مختلفی برای مقیاس‌گرفتن به خارج (Scale out) وجود دارد. یک روش که بوسیله آمازون محبوب شد و در اصل آن را بر روی محصول داخلی Dynamo ساختند، از درهم‌سازی سازگار (Consistent Hashing) استفاده می‌کرد. در این روش، اساساً، چیزها را حول یک حلقه درهم‌سازی‌ها قرار می‌دهید و این مشخص می‌کند که [داده‌ها] برروی چه سروری قرار دارند و اگر آن سرور خراب باشد، بر روی چه سرور [دیگری] قرار می‌گیرد. بنابراین دسته راه‌حل‌های درهم‌سازی سازگار، یکی از این مدل‌های توزیع‌شدگی است.
مدل دیگر، چندپاره کردن خودکار (Auto-sharding) است و این مدل بوسیله گوگل با BigTable متداول شد. در این مدل، ما مجموعه‌ای از داده‌ها که می‌خواهیم پارتیشن کنیم را برمی‌داریم و بازه‌های کلید (Key Range) تعریف می‌کنیم که به مانند تکه‌هایی از داده‌ها هستند که مثلاً ۱۰۰ مگابایت اندازه دارند و متادیتایی در مورد آن تکه‌ها نگه می‌داریم تا بتوانیم به خاطر بیاوریم که فرضاً تمام داده‌های موجود در این بازه کلیدها، در پاره شماره ۲۹ قرار دارد. سیستم این کار را می‌کند و این دو رهیافت مزایا و معایب خودشان را دارند.
برای ترجیح دادن یکی از آن‌ها، نکات اصلی کدام است؟
درهم‌سازی سازگار، زیبا و ساده است که یکی از نقاط قوتش است؛ در آن خیلی واضح است که چطور باید گره‌های جدید را به سیستم اضافه کرد و چطور باید آن‌ها را خارج کرد. از این نظر، خیلی تمیز است. مدل چندپاره کردن (Sharding) شاید پیاده‌سازی پیچیده‌تری داشته باشد اما مطلب اصلی که آنجا حاصل می‌کنیم این است که یک روش پارتیشن کردن حافظ ترتیب (Order Preserved) بدست می‌آوریم یعنی این گرایش هست که کلیدهایی که به هم نزدیک هستند، بر روی ماشین یکسانی قرار گیرند بنابراین انجام یک پرس‌وجوی بازه‌ای با یک سیستم درهم‌سازی سازگار دشوار است و این موضوع می‌تواند اهمیت یابد.
وقتی به این سیستم‌ها دقت می‌کنم موضوعی هست که به درستی متوجه نمی‌شوم. شما می‌توانید چیزی مانند Voldemort داشته باشید که یک ذخیره‌گاه کلید/مقدار (Key/Value Store) است و یک سیستم کلاس A است و از مدل توزیع داده‌های آمازون استفاده می‌کند و بعد، MongoDB را دارید که سندگرا است و از مدل چندپاره کردن خودکار استفاده می‌کند و یک سیستم کلاس C است. اما آیا می‌توانم در هرکدام از این ستون‌ها، هر گزینه‌ای را انتخاب کنم و ویژگی‌های موردنظرم را فراهم کنم؟ (اشاره به ۳ محوری است که در این مصاحبه بحث شد. یعنی محوری که مدل داده‌ها را تعیین می‌کند، محوری که مدل ویژگی‌های غیرعملکردی از دیدگاه تئوری CAP را بیان می‌کند و در نهایت محوری که مدل توزیع‌شدگی را بیان می‌کند -مترجم) آیا این ۳ محور بر روی همدیگر محدودیت ایجاد نمی‌کنند؟
تا حد زیادی می‌توانید انتخاب کرده و [ویژگی مورد نظر را] اختیار کنید. می‌توانید بگویید فلان و بهمان ویژگی را می‌خواهم و آن سیستم را بسازید.
سیستمی که حداقل از نظر مدل ذخیره‌سازی، بیش از همه با MongoDB قابل مقایسه باشد، CouchDB است. شما Mongo را با CouchDB چگونه مقایسه می‌کنید؟
از بعضی جنبه‌ها، یکسان هستند. هر دو پایگاه‌های داده JSON هستند که فکر می‌کنم چیز خوبی است. هر دو از نظر ویژگی‌ها و عملکردها، کاملاً غنی هستند و در طیف پرعملکردها قرار می‌گیرند. اما روشی که سیستم را بکار می‌گیرید و با آن صحبت می‌کنید کاملاً متفاوت است. Couch برای صحبت با پایگاه داده، از یک واسط REST استفاده می‌کند درحالیکه ما در Mongo مانند پایگاه‌ داده‌های سنتی، برای صحبت با پایگاه داده، از یک پروتکل اختصاصی بومی استفاده می‌کنیم. بنابراین ما برای هر زبان برنامه‌نویسی یک کلاینت داریم که بتوانید با Mongo صحبت کنید که از آن پروتکل اختصاصی استفاده می‌کند. و به منظور کارایی (Efficiency) این کار را کرده‌ایم. ما به جای استفاده از REST، می‌خواهیم چیزی را بسازیم که طبق پروتکل، دقیقاً همان چیزی باشد که می‌خواهیم انجام دهیم. بنابراین کاملاً به خاطر دلایل کارایی بوده است و اگرنه REST فرمت استاندارد خیلی خوبی است. بنابراین این تفاوت هست.
به علاوه، روشی که پرس‌وجوها در دو سیستم کار می‌کنند کاملاً متفاوت است. در Couch برای تعریف کردن یک پرس‌وجو، اساساً یک View می‌سازید که با تعدادی تابع Map-Reduce تعریف می‌شود و آن توابع، View را تجسم می‌بخشند. این به شدت زیبا و عالی است اما به این معنی است که مجبورید این Viewها را از قبل تعریف کنید. اما در Mongo ما از پرس‌وجوهای موردی سنتی‌تر استفاده می‌کنیم و زبان پرس‌وجوی Mongo را دارید که درواقع به شکل JSON است. بعد ما بهینه‌سازی پرس‌وجو را اجرا می‌کنیم و شما یک طرح پرس‌وجو می‌سازید و پرس‌وجو را اجرا می‌کنید. همینطور می‌توانید دقیقاً همانند یک پایگاه MySQL سنتی، شاخص‌هایی هم تعریف کنید. بنابراین این یک رهیافت سنتی‌تر است اما چیز خوبی که دارد این است که می‌توانیم پرس‌وجوهای موردی (Ad-hoc) داشته باشیم.
یکی از دیگر تفاوت‌ها این است که Couch در رونوشت‌برداری ارشد/ارشد (Master/Master) بهمراه همگام‌سازی مربوط به بعد از یک دوره خارج از خط بودن، بسیار خوب است. بنابراین CouchDB، بخاطر مسائل همگام کردن‌های برخط و خارج از خط، خیلی خوب است. اما Mongo بیشتر به مسائلی گرایش دارد که یک مدل سازگاری قوی را می‌خواهید و برای حل و فصل کردن تفاوت در نسخه‌ها (Version Reconciliation) که در رونوشت‌برداری‌های ارشد/ارشد پیش می‌آید، نمی‌خواهید خودتان کد بنویسید. مثلاً اگر به یک وضعیت سراسری نیاز داشته باشید و بخواهید یک شاخص کلید منحصر بفرد (Unique Key) داشته باشید، چنین کاری در رونوشت‌برداری ارشد/ارشد مشکل‌زا است. بنابراین فکر می‌کنم که [Mongo] مثلاً برای تولید برنامه‌های تحت وب خیلی خوب کار می‌کندو نقطه‌ی قوتش است. یک تفاوت دیگر هم این است کهCouch به زبان Erlang نوشته شده درحالیکه Mongo به زبان C++ است.
آیا MongoDB برای عملیات‌هایی که بتوان بر روی سرور انجام داد، نسبت به ذخیره‌گاه‌های کلید/مقدار (Key/Value Store)، مجموعه عملکردهای خیلی غنی‌تری را فراهم می‌کند؟
بله.
پس باید برای اینکه چنین چیزی را بدست آورم هزینه‌ای بپردازم چون این همه امکانات پرس‌وجو را نمی‌توان مجانی داشت.
سئوال خوبی است. به عقیده من، هزینه زیادی برای‌‌تان ندارد. روشن است که هم سیستم‌های دارای مدل داده‌ BigData و هم سیستم‌های سندگرای JSON، هر دو می‌توانند نوع داده‌های کلید/مقداری را ارائه دهند چون این زیرمجموعه‌ای از مجموعه مسائلی است که آن‌ها می‌توانند ارائه کنند. بنابراین سئوال تنها این است که آیا کندتر می‌شوم؟ آیا چیزهایی را از دست می‌دهم؟ و از این قبیل سئوال‌ها. اما من فکر نمی‌کنم که چیز خیلی زیادی را از دست بدهید. فکر می‌کنم تأثیر خیلی اندکی بر روی کارایی (Performance) داشته باشد. فلسفه ما این است که وقتی شما ویژگی‌هایی به پایگاه داده می‌افزایید جایی می‌رسد که کندتر می‌شوید و مقیاس‌پذیری‌تان کاهش می‌یابد اما ما فکر می‌کنیم که در این منحنی، یک نقطه اوج‌گیری وجود دارد (گوینده، از عبارت Knee in the curve استفاده می‌کند. با توجه به این مقاله و تعریفی که از Knee در آن ارايه شده است، ترجمه اوج‌گیری برای آن انتخاب شد -مترجم). فکر می‌کنیم می‌توان حجم خوبی عملکرد اضافه کرد اما نقطه خاصی هست که وقتی به آن می‌رسید، اگر بخواهید پیشتر بروید، ۱۰ مرتبه کندتر می‌شوید. بنابراین ما تلاش می‌کنیم که تا جایی که بشود به آن نقطه اوج‌گیری نزدیک شویم اما بیشتر جلو نرویم. بنابراین ما حدود ۷۵-۸۰ درصد از عملکردهای پایگاه داده‌های سنتی را فراهم می‌کنیم و همچنان این ویژگی‌های جدید و خیلی جالبِ مقیاس‌پذیر بودن و راحتی توسعه را هم داریم. بنابراین ما چند چیز را بیرون خواهیم گذاشت اما نه اینکه ۸۰ درصد چیزها را بیرون بگذاریم که به نوعی یک شکل ساده کلید/مقدار از آن حس کنید.
پروژه متن‌باز MongoDB با 10gen بعنوان حامی، چطور سازماندهی شده است؟
بله، این پروژه متن باز است و بر روی Github قرار دارد. در واقع در اصل، ما در 10gen پروژه را آغاز کردیم اما الان مشارکت‌کننده‌های خارجی داریم که در انجمن خیلی فعال هستند. در حال حاضر، شرکت‌های دیگری هستند که حول MongoDB کسب‌وکارهایی ساخته‌اند مثلاً MongoHQ هست که یک شرکت دیگر است که میزبانی Mongo تحت سرویس‌ ابری را انجام می‌دهد که تنها از همان پروژه متن‌باز استفاده می‌کند (هم‌اکنون 10gen به شرکت MongoDB و شرکت MongoHQ به Compose تغییر نام داده است -مترجم). بنابراین این یک پروژه متن‌باز است و ما عاشق متن‌باز هستیم و می‌خواهیم که افراد زیادی باشند که در انجمن مشارکت داشته باشند و کامیت کنند و مشارکت‌های خوب دیگر داشته باشند.
چه فضاهای خاصی وجود دارد که انجمن، در آن مشارکت دارد؟ خصوصاً در زمینه افزونه‌ها (Add-on)؟
فکر می‌کنم درایورهای زیادی توسط انجمن نوشته شده است. همینطور بر روی درایورها فریم‌ورک‌های داده‌ای هستند که توسط انجمن نوشته شده است مثلاً MongoMapper که پیش از این توضیح دادیم. واسط‌های کاربری برای امور مدیریتی هم وجود دارند که توسط انجمن نوشته شده است. جمعی هم هستند که بر روی هسته پایگاه داده کار می‌کنند. به علاوه بحث مستندسازی‌ها هم هست. خیلی از افراد، در بحث مستندات و ترجمه آن‌ها به زبان‌های دیگر، مشارکت دارند. همینطور تبلیغات، آموزش و این چیزها.
اگر افراد بخواهند بیشتر یاد بگیرند یا شاید درگیر کار شوند چه می‌توانند بکنند؟
اگر می‌خواهند درگیر شوند می‌توانند به info@10gen.com ایمیل بزنند و ما کمک‌شان می‌کنیم. می‌توانند یک‌راست به کانال IRC ما بیایند و با افراد گفتگوی زنده داشته باشند و درگیر شوند. ما عاشق این هستیم.
چه ویژگی‌هایی جالبی را می‌توانیم در انتشار بعدی نسخه سرور انتظار داشته باشیم؟
انتشارهایی که شماره نسخه زوج دارند، نسخه‌های پایدار (Stable) هستند و این‌ها هستند که برای‌تان اهمیت دارد. در نسخه ۱.۴ که الان بیرون آمده، یکی از مهمترین مواردی که آمده است، قابلیت ایجاد شاخص برای داده‌های نوع مکانی (Geo-spatial) است که ویژگی خوبی است که اگر برنامه‌های موبایلی می‌نویسید به آن نیاز دارید. ریلیز ۱.۴ که تابستان خواهد آمد، درمورد مقیاس‌پذیری است. یعنی امکان چندپاره کردن محصول عملیاتی (Production Sharding) و یک انتشار جدید از رونوشت‌برداری (Replication) در نسخه ۱.۶ بیرون خواهد آمد که واقعاً امکان خوشه‌های بزرگ عملیاتی باکیفیت را فراهم می‌آورد. این‌ها، همه کارهایی است که الان به آن می‌پردازیم. و در پاییز کار‌هایی بر روی چیزهای دیگری خواهیم داشت که شامل مانایی تک سروره (Single Server Durability) و موتور ذخیره‌سازی، کار بر روی Map/Reduce و افزایش کارایی، کار بر روی جستجو‌های تمام‌ متنی (Full Text Search) و چیزهایی از این قبیل است. البته برای همه این‌ها یک تاریخ تحویل دقیق نداریم اما این‌ها در نقشه راه قرار گرفته‌‌اند.
افرادی که علاقه‌مندند شما را دنبال کنند...
بله، اگر به وب‌سایت 10gen بروید در صفحه «درباره ما»، لینک‌هایی به بلاگ من و توییترم هست. توییترم @dmerr است.
چه تعداد افرادی از MongoDB استفاده می‌کنند؟
در ماه مارس، ۳۷۰۰۰ دانلود پایگاه داده داشتیم و این بغیر از [دانلود] درایورها و مستندات و این جور چیزها است و عدد خالصش است. بنابراین ما فکر می‌‌کنیم جایی از بازار که الان قرار گرفته‌ایم خیلی خوب است. ۶ ماه پیش این عدد ۱۰ برابر کوچکتر بود. ما شاهد شتاب خیلی خوبی در میزان استفاده از محصول بوده‌ایم. الان جاهایی مانند Foursquare و SourceForge و Github و New York Times دارند از آن استفاده می‌کنند. بنابراین خیلی جالب است و فکر می‌کنم استفاده چشمگیری از آن هست.
از سهم بازاری که NoSQL در بازار ذخیره‌گاه‌ها دارد، نوعی آمار شبه علمی به ما بدهید.
بله. همچنان کوچک است اما گرایش روشنی وجود دارد که قطعاً رخ خواهد داد. ما امروز اینجا در کنفرانسی هستیم که ۲۰۰ نفر در سانفرانسیسکو گردآمده‌اند و فقط در مورد MongoDB است نه اینکه در مورد کل فضای NoSQL باشد. فعالیت‌های زیادی آغاز شده است. فکر می‌کنم در فضای کارهای وب، تا انتهای امسال طوری باشد که برای آغاز توسعه یک برنامه جدید، افرادی که از یک راه حل NoSQL استفاده کنند بیشتر از آن‌هایی باشد که از راه‌حل‌های پایگاه‌های رابطه‌ای سنتی استفاده می‌کنند. البته این در مورد برنامه‌های تحت وب است، در مورد کل فضا نیست چون این فضا است که تطبیق زودهنگامی با NoSQL داشته است. ما داریم به نقطه‌ای می‌رسیم که استفاده‌اش کاملاً چشمگیر خواهد شد. البته [تا بحال] این کاربرد خیلی بزرگ و همچنان مبنایی از پایگاه‌های رابطه‌ای را داشته‌اید؛ حتی اگر ما در همه این راه‌حل‌های NoSQL نرخ‌های بالای دانلود ماهانه را بدست آوریم، همچنان فرضاً ۳۰ ماه طول می‌کشد تا اینکه به نقطه‌ای برسیم که برنامه‌های زیادی از آن استفاده کنند و مورد استفاده‌ی کاربران قرار بگیرند و اطلاعات در آن‌ها نوشته شود.
دوآیت مریمن، از گفتگو با SE Radio خیلی متشکرم.
ممنونم.