همه چیز در باره جنبش NoSQL !
Loading
صفحه 1 از 2 12 آخرینآخرین
نمایش نتایج: از 1 به 10 از 19

موضوع: همه چیز در باره جنبش NoSQL !

  1. #1
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,820
    Thanks
    22
    Thanked 47 Times in 42 Posts

    Post همه چیز در باره جنبش NoSQL !




    اصطلاح NoSQL نامی عمومی است که به مجموعه‌ای از پایگاه‌های داده اطلاق می‌شود که از زبان پرس‌وجوی ساخت‌یافته SQL (سرنام Structured Query Language) یا مدل داده رابطه‌ای استفاده نمی‌کنند. گاهی این اصطلاح را مخفف Not Only SQL می‌دانند تا تأکید کنند که طرفداران انواع پایگاه‌های داده غیررابطه‌ای معتقدند که پایگاه‌های داده رابطه‌ای سنتی تنها راه موجود برای ذخیره‌سازی داده نیستند، اما این به آن معنا نیست که به خودی خود انتخاب نادرستی باشند. این اصطلاح نخستین‌بار توسط اریک اوانس از Rackspace به کار رفت. او که یکی از توسعه‌دهندگان کاساندرا است، پس از آن از به کار بردن این اصطلاح خودداری می‌کند و به جای آن مایل است اصطلاح BigData یا داده‌های عظیم را به کار ببرد تا این گروه از پایگاه‌های داده را نه بر‌اساس چیزی که نیستند (سازگار با SQL) بلکه بر‌اساس کاری که می‌کنند (مدیریت مقادیر عظیم داده) تعریف کند. دوره استفاده از این اصطلاح کم‌وبیش به پایان رسیده است چرا که بسیار گیج‌کننده است و به نظر می‌رسد باعث می‌شود راجع به مجموعه‌ای از پایگاه‌های داده بحث کنیم که در عمل میزان شباهت میان اهداف، ایده‌های طراحی و قابلیت‌های آن‌ها بسیار اندک است. بهتر است بگذاریم کاساندرا همان کاساندرا، CouchDB همان CouchDB و Riak همان Riak بماند.


    اهمیت و کاربرد

    عبارت NoSQL یک مفهوم برای مشخص‌سازی یک موج خلاقانه است که در دنیای پایگاه‌هاي داده‌اي در حال وقوع است. با مطرح شدن این مفهوم، طوفانی از تبادل نظر، هیجان و بحث و گفت‌وگو در محافل فنی به راه افتاد که به يقين تا مدت‌ها باقی خواهد ماند. اما چرا NoSQL این همه سروصدا به پا كرده است؟ این مفهوم برای یک توسعه‌دهنده برنامه‌هاي کاربردی چه معنايی دارد؟ همان‌طور که قبلاً نیز ذکر‌شد، زبان SQL و پیاده‌سازی‌هاي مختلف SQL RDBMS (Relational Database Management Systems) مانند MySQL، PostgreSQL، Oracle و... دهه‌هاي متمادی برای تمام نیازهای ذخیره‌سازی و بازیابی داده کاربران و توسعه‌دهندگان یک راه حل اساسی بوده‌اند. اما در سال 2010، نیازمندی‌هايي‌مطرح شده و مورد توجه قرار‌گرفتند که با استفاده از مدل رابطه‌اي سنتی قابل دستیابی نبودند. از آنجا که مسائل جدید به ابزارهای جدید نیاز‌دارند، مجموعه‌اي بزرگ از ابزارها پا به عرصه وجود گذاشته و مورد‌توجه بسیاری قرار‌گرفتند. دسترس‌پذیری بالا، مقیاس‌پذیری‌افقی، قابلیت تکثیر (Replication)، طراحی بدون Schema و قابلیت Map Reduce از جمله زمینه‌هايي هستند که توسط مجموعه‌اي جدید از پایگاه‌هاي داده و تحت عنوان کلی NoSQL در حال توسعه و آزمایش هستند.

    برای درک بيشتر اهمیت NoSQL بايد به چالش‌هاي موجود امروزی بر سر راه پایگاه‌هاي داده بيشتر توجه کرد. هم‌اکنون با توسعه فناوري‌هاي مختلف و قابلیت نمونه‌برداری و تولید حجم عظیمی از داده‌ها، امکان ذخیره‌سازی و تحلیل آن‌ها چالشی بزرگ به شمار مي‌آيد. داده‌هايي مانند داده‌هاي هواشناسی، فعالیت‌های آنلاین کاربران یا تحلیل‌هاي اقتصادی در قالب پایگاه‌هاي داده‌اي سنتی کارایی چندانی نخواهند داشت و در ذخیره‌سازي‌های بدون قالب و توزیع شده‌اي مانند هادوپ به بهترین روش کار خواهند‌کرد. همچنين، امروزه سرویس‌دهندگان بسیاری به ذخیره‌سازی و ارائه محتوای عظیم باینری به کاربران خود در شبکه نیاز دارند که در نوع خود، چالشی بسیار بزرگ به شمار مي‌آيد. کارایی بسیار بالا در ذخیره‌سازی و ارائه داده‌هاي باینری مانند اسناد PDF و فایل‌هاي MP3، در مقیاس وسیع، یکی از بهترین کاربردهایی است که پایگاه‌هاي داده‌اي NoSQL شایستگی خود را در فراهم‌کردن آن به اثبات رسانده‌اند. یک نمونه مناسب در این زمینه، خدمات Amazon S3 است. با این اوصاف، موارد ذکر شده تنها چالش پیش روی توسعه‌دهندگان و سرویس‌دهندگان نیست. ذخیره‌سازی، مدیریت و بازیابی داده‌هاي گذرا که در بعضی موارد در مقیاس بالایی در برنامه‌هاي کاربردی امروزی تولید مي‌شوند نیز یکی دیگر از چالش‌هاي امروزی است که راه حل مدیریت مناسب آن‌ها را پایگاه‌هاي داده‌اي NoSQL ارائه‌کرده‌اند. این پایگاه‌هاي داده، در مدیریت داده‌هايي نظیر متغیرهای یک Session در وب، قفل‌هاي داده‌اي و آمار کوتاه مدت، جایگاه بسیار‌خوبي کسب کرده‌اند. نمونه مناسبی برای این کاربرد، پایگاه داده‌اي Memcached است. اما نکته‌اي که باید در این میان به آن توجه کرد آن است که یک توسعه‌دهنده، باید برای کاری که مي‌خواهد انجام دهد، ابزار مناسب را انتخاب‌کند. به این معنا که برای بسیاری از کاربردهای معمولی، هنوز پایگاه‌هاي داده‌اي سنتی بهترین راه حل هستند و نباید آن‌ها را تمام شده تصور كرد. همان‌طور که قبلاً نیز گفته شد، پایگاه‌هاي داده‌اي NoSQL برای مواردی خاص‌مناسب هستند که در بالا به آن‌ها اشاره شد و موجب افزایش کارایی‌کل مجموعه نرم‌افزاری مي‌شوند. در بسیاری از موارد، انتخاب یک پایگاه داده NoSQL برای کاربردی خاص موجب افت شدید عملکرد و عدم پایداری مجموعه و قابلیت اطمینان بسیار پایین مي‌شود. به همین دلیل و به علت تعدد ابزارهای توسعه‌داده شده در این زمینه، گاهی اوقات تشخیص محدودیت‌ها و مصالحه‌هايي که باید در استفاده از یک ابزار در‌نظر گرفت، بسیار مشکل شده و انتخاب راه حل مناسب در محیط‌هاي رابطه‌اي یا غیر رابطه‌اي یک یا چند سروری، سردرگم کننده خواهد بود. به همین منظور، یک دیاگرام مناسب برای انتخاب راه حل مناسب توسط ناتان هورست (Nathan Hurst ) بر‌اساس نظریه CAP طراحی شده که در شكل ۱ آن را مشاهده مي‌كنيد.



    در این دیاگرام سه گوشه اصلی نشانگر ثبات (Consistency)، در دسترس بودن (Availability) و قابلیت بخش بخش سازی (Partition Tolerance) هستند. ثبات در اینجا يعني همه کلاینت‌ها همواره به داده‌هاي مشابه دسترسی داشته باشند، در دسترس بودن يعني همه کلاینت‌ها امکان خواندن و نوشتن را داشته باشند و قابلیت بخش بخش سازی نیز به معنای این است که سیستم کلی بتواند در تمام بخش‌هاي شبکه فیزیکی کار‌کند. بر اساس نظریه CAP، تنها دو عنصر از این سه عنصر در سیستم‌هاي واقعی قابل انتخاب هستند و بر همین اساس، برای داشتن هر جفت مشخصه، مي‌توان راه‌حلی را که روي ضلع مشترک آن‌ها آورده شده است، انتخاب كرد. بررسی کامل این دیاگرام خود محتاج توضیح و تبیین بسیاری است که در حوصله این مقاله نمی‌گنجد. راهکارهای NoSQL، برای مسائلی بسیار فراتر از دنیای سنتی پایگاه‌هاي داده‌اي به‌کار‌مي‌روند و عملکردی به شدت بهتر از همتایان سنتی خود ارائه‌مي‌كنند. لازم به تأکید است که گذار به سمت راهکارهای NoSQL، به دلیل مشکلات و محدودیت‌هاي زبان SQL نبوده است، بلکه به‌دليل محدودیت‌هاي مدل رابطه‌اي پایگاه داده‌اي است. زمینه‌هايي که این پایگاه‌هاي داده‌اي مناسب آن‌ها هستند و از خود شایستگی بیشتری در آن‌ها نشان مي‌دهند، به ترتیب در ادامه آورده شده‌اند:
    داده‌هاي با توالی نوشتن بالا و توالی خواندن کم:
    همانند شمارنده‌های بازدید صفحات وب، دستگاه‌هاي وقایع‌نگار یا تلسکوپ‌هاي فضایی. در این حالت، ذخیره داده‌ها یا به‌صورت جفت‌هاي داده‌اي key-value (همانند آنچه در Redis اتفاق مي‌افتد) انجام مي‌گیرد یا به صورت Document Oriented (همانند مدل مورد استفاده MongoDB) صورت مي‌پذیرد.
    داده‌هاي با توالی خواندن بالا و توالی نوشتن بسیار‌کم:
    همانند داده‌هاي‌گذرا و کش شده‌اي از تصاویر، اسناد و HTML رندر شده با دسترسی تکراری. چنین داده‌هايي در پایگاه‌داده Memcached که برای ذخیره موقت داده‌هاي گذرا مورد استفاده قرار مي‌گیرد، به خوبی مورد پردازش قرار مي‌گیرند. پایگاه‌هاي داده‌اي Cassandra و HBase نیز در زمینه جست‌وجوي داده‌هاي عظیم شایستگی‌هاي بسیاری دارند و راه‌حل‌هاي پیشرفته‌اي نظیر Hadoop و Hive نمونه‌هايي مناسب برای استفاده در زمینه تحلیل داده‌ها به شمار مي‌روند.
    کاربردهايی با نیازمندی‌هاي در دسترس بودن بالا (High Availability) و با توقف خدمات (Downtime) بسیار‌کم:
    این موارد به شدت در مدل سنتی با کمبودهایی مواجه هستند و پایگاه‌هاي داده‌اي NoSQL از عهده اجرای آن‌ها به‌خوبی ‌بر‌مي‌آیند. چنین سیستم‌هايي که از طریق مجموعه‌هاي خوشه‌سازی شده و با پیکربندی Redundant پیاده سازی مي‌شوند، بیش از هر چیز به مقیاس پذیری افقی و امکان توسعه روی ماشین‌هاي مختلف شبکه نیاز دارند. با مدل‌های ارائه شده جدید توسط پایگاه‌هاي داده‌اي مانند Riak و Cassandra انطباق بیشتری داشته و کارایی بالاتری ارائه مي‌كنند.
    داده‌هايي که باید در نقاط مختلف جغرافیایی با هم همگام‌سازی شوند:
    چنین داده‌هايي که در کلاسترهای مختلف یک شبکه بزرگ‌سازمانی با دفاتر مختلف پراکنده در سطح جغرافیایی وسیع موجودند و نیاز است تا همواره و با بالاترین سرعت و کمترین هزینه ممکن با هم همگام سازی شوند، به خوبی در مجموعه‌هاي سنتی رابطه‌اي قابل پیاده‌سازی نیستند و در صورت انجام این کار، هزینه‌هاي بسیاری را در بر‌خواهند داشت. در نقطه مقابل، پایگاه داده‌اي Memcached به خوبی از عهده اجرای چنین عملیاتی با کمترین هزینه و بالاترین کارایی بر‌مي‌آید.
    داده‌هاي بزرگ تجاری یا مرتبط با تحلیل وب که شما ( schema‌)ی خاصی ندارند:
    چنین داده‌هايي تقریباً شکل و قالب از پیش تعیین شده‌اي ندارند و بر‌اساس محتوای متغیر موجود روي وب تولید مي‌شوند و در بيشتر موارد به فعالیت‌کاربران و سیستم‌هاي نرم‌افزاری مرتبط وابسته‌هستند. اغلب نیاز است تا چنین داده‌هايي به خوبی ذخیره‌سازی شوند (ترجیحاً به‌صورت موازی) و امکانات پرس‌و‌جو‌پذیری غنی در اختیار بگذارند تا به خوبی قابل تحلیل باشند. مشخص است که سیستم‌هاي سنتی داده‌اي که برای ذخیره‌سازی و بازیابی نیاز به داشتن یک شمای از پیش تعیین شده و ثابت دارند به خوبی از عهده چنین‌عملیاتی بر‌نمی‌آیند و به استفاده از راهکارهای جدید در این زمینه نياز است. راه حل هادوپ یکی از بهترین گزینه‌ها برای کارکرد به‌عنوان مدیر چنین داده‌هايي است.
    راه‌حل‌هاي NoSQL در بسیاری از شرکت‌هايي که خدمات «وب اجتماعی» ارائه مي‌كنند، به کار گرفته شده و به سرعت در حال گسترش است. این امر به دلیل سختی زیاد و محدودیت‌هاي سیستم‌هاي کاملاً رابطه‌اي در برآورده‌کردن نیازهای داده‌اي آن‌ها است. با نگاهی به نیازمندی‌هاي مقیاس پذیری یکی از شبکه‌های اجتماعی به راحتی مي‌توانیم به این امر واقف شویم. این نیازمندی‌ها عبارتند از:
    - 570 میلیون مشاهده صفحات در ماه
    - آپلود بیش از سه میلیارد عکس در ماه
    - پردازش و ارائه بیش از 1,2میلیون عکس در ثانیه
    - ارائه 25 میلیون نوع محتوا که با استفاده از ۳۰ هزار سرور انجام مي‌پذیرد.
    با این نیازمندی‌ها، که به يقين با نیازمندی‌هاي یک دپارتمان حسابداری در دهه 1950 تفاوت‌هاي بسیاری دارد، این شبکه اجتماعی خود را با مجموعه‌اي غنی از ابزارها تطبیق‌داده است که هر کدام یکی از بهترین نمونه‌هاي پیشرو در حوزه پایگاه‌هاي داده‌اي NoSQL محسوب مي‌شوند:
    Memcached:
    این شبکه اجتماعی با استفاده از هزاران سرور Memcached، ده‌ها ترابایت داده کش‌شده گذرا را در هر لحظه پردازش‌كرده و خدمات مرتبط را به کاربران خود ارائه مي‌كند.
    Cassandra که هم اکنون با HBase جایگزین‌شده است:
    با استفاده از این پایگاه‌هاي داده‌اي این شبکه اجتماعی عملیات ذخیره‌سازی گسترده طیف وسیعی از داده‌ها بدون داشتن هیچ نقطه خطا دار یا مشکل داری در مجموعه عظیمی از ماشین‌هاي محاسباتی را به بهترین نحو به اجرا در مي‌آورد.
    Hadoop و Hive:
    با استفاده از این ابزارهای پیشرفته، این شبکه اجتماعی تحلیل داده‌هاي عظیم و تحلیل‌هاي بازاری و تبلیغاتی را با کارایی بالایی به انجام مي‌رساند.

    گذار به سمت راهکارهای NoSQL، به دلیل مشکلات و محدودیت‌هاي زبان SQL نبوده است، بلکه به‌دليل محدودیت‌هاي مدل رابطه‌اي پایگاه داده‌اي است.
    داده‌هايي مانند داده‌هاي هواشناسی، فعالیت‌های آنلاین کاربران یا تحلیل‌هاي اقتصادی در قالب پایگاه‌هاي داده‌اي سنتی کارایی چندانی نخواهند داشت و در ذخیره‌سازي‌های بدون قالب و توزیع شده‌اي مانند هادوپ به بهترین روش کار خواهند‌کرد.

    با توجه به موارد ذکر شده در بالا، مي‌توان معماری داده‌اي جدید و کارا را کلید رشد و توسعه سریع این شبکه اجتماعی دانست که به‌عنوان دلیل اصلی مقیاس پذیری خوب آن نیز به شمار آورد. عاملي که زمینه رشد و توسعه شرکت‌هاي بزرگ دیگری مانند یاهو، Foursquare و Twitter را نیز به ارمغان آورده است. با این‌که این‌گونه شرکت‌ها در زمینه استفاده از این فناوري‌ پیشگام هستند، اما هسته اصلی فناوری NoSQL به کار گرفته شده در بسیاری از کاربردهای موجود به‌صورت کلی در دسترس همگان قرار دارد که در بیشتر موارد به‌صورت اپن سورس نیز توسعه داده شده‌اند. به همین دلیل، طیف وسیعی از توسعه دهندگان در برنامه‌هاي‌کاربردی و تجاری خود در حال آزمایش و تطبیق با این فناوري نوپا هستند و به زودی شاهد موج عظیمی از به‌کارگیری چنین فناوری‌هايي در گوشه و کنار دنیای نرم افزارها خواهیم بود.

    منبع : ماهنامه شبکه
    ویرایش توسط admin : Monday 20 May 2013 در ساعت 01:41 PM
پاسخ با نقل قول پاسخ با نقل قول

  • The Following User Says Thank You to admin For This Useful Post:

    VBkar (Saturday 25 May 2013)

  • #2
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,820
    Thanks
    22
    Thanked 47 Times in 42 Posts

    Post آیا NoSQL مرگ پایگاه داده رابطه ای را رقم می زند؟



    اگر گمان مي‌کنيد که ديتابيس‌هاي SQL همه از نوع رابطه‌اي هستند، بايد بگوييم که اشتباه مي‌انديشيد. NoSQL يك پايگاه داده‌اي غيررابطه‌اي و توزيع شده است که نيازي به جدول ندارد و مي‌تواند به‌سادگي عمليات Replication را انجام دهد.پايگاه‌هاي داده رابطه‌اي در نرم‌افزارهايي كه داده‌هاي سنگيني دارند، بازدهي كمي دارند. مثلا براي انديس‌گذاري تعداد زيادي از سندها يا ارائه صفحه‌هاي اينترنت در وب‌سايت‌هايي كه جريان داده بالايي دارند، پايگاه‌هاي داده رابطه‌اي پاسخگو نخواهند بود و تنها زماني به‌درد مي‌خورند كه يا داده‌ها اندك باشد يا درخواست نوشتن و خواندن در ديتابيس زياد نباشد. به‌عنوان مثال، پايگاه داده ديگ كه 3ترابايتي است يا پايگاه داده فيس‌بوك كه براي جستجوي اينباكس‌هاي كاربران، 50ترابايت داده دارد، همچنين پايگاه داده eBay كه هم‌اكنون به 2پتابايت رسيده است، نمي‌توانند كار خود را با پايگاه‌هاي داده رابطه‌اي راه بيندازند.

    به همین دلیل است که ديتابيس‌هاي NoSQL آنجايي جذاب مي‌شوند که ضعف‌هاي RDBMS به‌چشم مي‌خورد: اين پايگاه‌هاي داده براي يک کاربر و يک دستگاه و يک عمليات در لحظه ساخته شده‌اند. RDBMSها جوابگوي نظام محاسباتي فعلي دنيا نيستند که در لحظه هزارها و ميليون‌ها کاربر مي‌خواهند به پايگاه داده‌اي پر از تصوير و فيلم و داده ديجيتال دسترسي پيدا کنند.
    پايگا‌ه‌هاي داده NoSQL‌ نسل جديدي از پايگاه‌هاي داده هستند كه پشت بسياري از وب‌سايت‌هاي بزرگ و حجيم قرار گرفته‌اند و نوع ديگري از سرويس را نسبت به پايگاه‌هاي داده قديمي‌تر، يعني پايگاه‌هاي داده رابطه‌اي (Relational) ارائه مي‌كنند.
    در سال‌هاي اخير، پديده NoSQL به يک جنبش تبديل شد و در بسياري از کشورهاي توسعه‌يافته، اين شکل پايگاه داده را به‌عنوان پايگاه داده‌اي مطمئن در اختيار گرفته و استفاده کردند.البته ايده پايگاه داده NoSQL تقريبا 10 سال است که در محافل اينترنتي وجود داشته است.
    اين پايگاه داده را دو نام بزرگ پياده‌سازي کرده‌اند و همين باعث جلب توجه به چنين پايگاه داده‌اي شده است: آمازون دينامو و گوگل بيگ‌تيبل از ديتابيس‌هايي هستند که فرزند NoSQL به‌شمار مي‌روند. البته اين پايگاه داده انواع منبع‌باز مختلفي نيز دارد که مي‌توان از ميان آن‌ها به Cassandra ،CouchDB Hbase ،MongoDB Redis ،Riak و CouchDB اشاره کرد.
    در معماري NoSQL بحث ثبات داده‌ها تنها در مورد يك آيتم يا يك تراكنش اعمال شده است. هرچند برخي از سيستم‌هاي فعلي كاملا قابليت ACID را پشتيباني مي‌كنند.
    سيستم‌هاي NoSQL داده را با كمك معماري توزيع‌شده در چندين سرور با افزونگي خاص خود قرار مي‌دهند. به اين ترتيب سيستم مي‌تواند با افزوده شدن سرورهاي ديگر، خودش را بزرگ كند و به امنيت و پايداري سيستم كمك كند. برخي از پايگاه‌هاي داده NoSQL حتي رابط ساده‌اي براي ارتباط با اين ديتابيس‌ها در نظر گرفته‌اند و داده‌ها را به‌صورت آرايه‌هاي انجمني ذخيره كرده و دسترسي به‌داده‌ها را ساده‌تر مي‌كنند. هجوم كاربري‌هاي زياد از پايگاه‌هاي داده NoSQL و همچنين استفاده شركت‌هاي بزرگ از اين نوع پايگاه‌هاي داده، برخي را به اين تفكر واداشته است كه پايگاه‌هاي داده رابطه‌اي در حال مرگ هستند. اگر بخواهيم پاسخ كوتاه و قطعي بدهيم، بايد گفت بي‌گمان اين موضوع صحيح نيست. پايگاه‌هاي رابطه‌اي باقي خواهند ماند و كاري كه مي‌كنند هم تغيير نخواهد كرد: مديريت داده‌هاي كلي، ارتباط ساده، سرعت، بازدهي بالا، انعطاف‌پذيري و قابليت گسترش براي كاربران متوسط و كوچك.

    هر چند ديتابيس‌هايي چون SQL Server، اوراكل و ماي‌سه‌كوئل اين سادگي را مديون پيچيدگي دروني خود هستند. پاشنه آشيل اين بانك‌هاي اطلاعاتي آنجاست كه نمي‌توانند بسرعت بزرگ شوند و با حجم بالاي درخواست روبه‌رو شوند. اغلب پايگاه‌هاي داده رابطه‌اي مي‌توانند تا حد مناسبي بزرگ شوند و اين عمليات بزرگ شدن در يك سرور بخوبي انجام مي‌شود، اما وقتي كار به بيش از يك سرور مي‌كشد، بايد سراغ پيچيدگي‌هاي خاصي رفت تا بتوان اين ديتابيس‌ها را بين بيش از يك سرور مشترك كرد.

    بيايد فرض كنيم كه بيش از صدها يا هزاران سرور براي رشد سريع لازم باشد. پيچيدگي حاصل از اين رشد، غيرقابل توصيف خواهد بود و پايداري و سرعت پايگاه‌هاي داده رابطه‌اي به‌شدت پايين مي‌آيد و ضعف‌هاي آن‌را براي سيستم‌هاي توزيع شده بسيار بزرگ نشان مي‌دهد.
    براي چنين سرويس‌هايي راه‌حل استفاده از NoSQL است كه غيررابطه‌اي و توزيع‌شده هستند و قابليت توسعه افقي دارند. از اين‌رو شركت‌هاي بزرگ زيادي همچون گوگل و آمازون از اين پايگاه داده استفاده مي‌كنند، البته اين شركت‌ها از پايگاه داده خاصي استفاده نمي‌كنند و هر كدام از مدير ديتابيس‌هاي توليدي خود استفاده مي‌كنند. بنابراين تفاوت ميان كاربرد پايگاه‌هاي داده رابطه‌اي و كاربرد پايگاه‌هاي داده غيررابطه‌اي مشخص شده است. تنها مساله باقي مانده، انتقال به نسل نوين است.يکي از تحليلگران موسسه 451 معتقد است:‌ «NoSQL پايگاه داده‌اي است که توسط امثال گوگل، آمازون، فيس‌بوک و تويتر به‌کار گرفته مي‌شود.» به‌گفته او گوگل و ديگر شرکت‌هايي که نام برده شدند، از NoSQL براي بالابردن بازدهي و ميزان گسترش‌پذيري سيستم استفاده مي‌کنند و در مقايسه با ديتابيس‌هاي سنتي، صرفه‌جويي زيادي در هزينه و انرژي خواهند کرد.

    يکي از توسعه‌دهندگان پايگاه داده Riak که مشترياني همچون Comcast و Electronic Arts را در کارنامه خود دارد، معتقد است:‌ «دسترسي بالاي پايگاه‌هاي داده NoSQL چيزي است که در ديتابيس‌هاي سنتي نمي‌توان آن‌ها را يافت. اين دسترسي بالاست که اجازه خواندن و نوشتن همزمان را به‌ديتابيس NoSQL مي‌دهد.» گفتني است Riak در الکترونيک‌آرتز، به‌منظور ذخيره‌سازي اطلاعات هفت ميليون کاربر بازي آنلاين Warhammer در فيس‌بوک به‌کار مي‌رود که هر نيم دقيقه اطلاعات تک تک کاربران را به‌روز مي‌کند.

    CouchDB
    دمين کتز، يکي از موسسان شرکت Couchio و توسعه‌دهنده پايگاه CouchDB معتقد است: «شرکت‌ها و توسعه‌دهندگان از NoSQL به‌اين دليل استفاده مي‌کنند که تفکرات خود را با SQL نمي‌توانند پياده کنند.»
    از سوي ديگر، در پايگاه داده CouchDB به‌جاي دسترسي بالا، مساله کنترل توزيع بهتر پياده شده است و مي‌توان پايگاه‌داده سندگراي کاملا توزيع‌شده‌اي ايجاد کرد که به‌سادگي کنترل مي‌شود.
    برخلاف پايگاه‌هاي داده SQL که داده‌ها را در ساختارهاي بسيار منظمي ذخيره مي‌کردند و گزارش مي‌دادند، CouchDB تلاش دارد اين اطلاعات را در سندهاي مجزايي که ساختاري نصفه و نيمه دارند، ذخيره و بازيابي کند. به‌عبارت ديگر CouchDB براي نرم افزارهاي وب چندنفره (Collaborative) که مبتني بر سندها و پرونده‌ها هستند، بسيار مفيد خواهد بود. يکي از مشتريان اين پايگاه داده، BBC است که روزانه 150 ميليون درخواست را پاسخگو است.

    پايگاه‌هاي داده مبتني بر سند، از جديدترين سيستم‌هاي مديريت پايگاه‌هاي داده به‌ شمار مي‌آيند. (مثل لوسنت از همین آپاچی)
    اين نوع از پايگاه داده، بر خلاف ديتابيس‌هاي رابطه‌اي، داده‌ها را در جداول ذخيره نمي‌كنند و در نتيجه، هيچ اندازه ثابتي براي داده‌ها در نظر نمي‌گيرند. اما، از طرف ديگر، هر ركورد به‌عنوان سندي با ويژگي‌هاي خاص ذخيره مي‌شود. در اين سند، هر تعداد فيلد با هر طولي مي‌تواند ذخيره شود. براي مثال، سند زير را در نظر بگيريد:


    FirstName=”Bob”, Address=”5 Oak St.”, m Hobby=”Sailing”.
    اين سند مي‌تواند يك ركورد ديتابيس باشد. از طرف ديگر، سند زير هم مي‌تواند ركورد ديگري از همان ديتابيس باشد:


    FirstName="Jonathan", Address="15 Wanamassa Point Road", Children=("Michael,10", "Jennifer,8", "Samantha,5", "Elena,2").
    حتما به اين نكته توجه كرده‌ايد كه بين اين 2سند ممكن است فيلد يكسان وجود داشته باشد و ممكن است هر كدام براي خود ويژگي‌هاي خاصي داشته باشند. نكته جالب ديگر در مورد پايگاه‌هاي داده مبتني بر سند، اين است كه هيچ فيلدي امكان خالي بودن ندارد. به‌اين ترتيب، اين سيستم قابليت افزودن داده در هر زمان را دارد و فضا را نسبت به ديتابيس رابطه‌اي كمتر هدر مي رود. جالب است بدانيد اين نوع از پايگاه داده، به 3فرمت XML، YAML و JSON سندهاي خود را ذخيره مي‌كند.

    قبل از آنكه پروژه آپاچي، يعني ‍CouchDB كه پايگاه داده مبتني بر سند است را معرفي كنيم، لازم است اشاره‌اي داشته باشيم به كاربرد اين پايگاه داده در اوبونتو نگارش 10/9 كه در سرويس Ubuntu One خود از اين پايگاه داده براي همخواني و انتقال فايل‌ها بين چند سيستم استفاده مي‌كند.



    ريلكس باشيد
    كنار لوگوي ‍CouchDB، شعار Relax مشاهده مي‌شود.
    دليل اين كار اين است كه قرار است مشكلاتي كه ممكن است در ايجاد ديتابيس توزيع‌شده مبتني بر سند به‌وجود بيايد، با پايگاه داده كوچ حل شود. اين پايگاه داده كارهاي زيادي براي شما انجام مي‌دهد. تنها لازم است روي خود نرم‌افزار متمركز شويد و نگران مديريت يا مشكلات جانبي نباشيد.
    اين پايگاه داده همچنين رابط برنامه‌نويسي (API) ساده و قابل فهمي دارد كه RESTful است (از طريق REST مي‌توان داده‌ها را مستقیما ارسال يا دريافت كرد، یعنی زبان خاصی لازم نیست ! ...) اگر خودتان از اين پايگاه داده استفاده كنيد، متوجه خواهيد شد كه آنچه خوانديد تبليغات تجاري نيست.


    قابليت‌ها
    اين پايگاه داده قابليت‌هاي زيادي دارد كه گفتن همه‌ آن‌ها ممكن است. بنابراين ويژگي‌هاي اصلي آن را مطرح خواهيم كرد.
    ذخيره‌سازيسندها
    همانطور كه گفتيم، كوچ‌دي‌بي سندها را در خود ذخيره مي‌كند. اين داده‌ها را مي‌توانيد به‌عنوان يك سند يا مجموعه‌اي از چند جفت كليد و داده تصور كنيد. داده‌ها مي‌توانند به فرم‌ ساده‌اي مثل رشته، عدد يا تاريخ باشند، يا اين‌كه از ليست‌هاي مرتب شده و انواع آرايه‌ها تشكيل شده باشند. هر سند در ديتابيس كوچ يك شناسه منحصر به‌فرد دارد.

    اسيد
    ديتابيس كوچ‌ اسيد را به‌خوبي پياده كرده است (اسيد يعني اتميك بودن، ثابت بودن، ايزوله بودن و دوام داشتن يك عمليات است كه اطمينان مي‌دهد هر دستور در ديتابيس به‌طور كامل انجام شده است). اين پايگاه داده مجهز به كنترل موازي چند نگارشي (MVCC) است و برخلاف InnoDB يا اوراكل، مي‌تواند خواندن و نوشتن‌هاي موازي در حجم بالا را بدون هيچ مشكلي راه ‌بيندازد.

    نگاشت/كاهش View هاو ایندکس ها
    براي اينكه بتوان كمي ساختار به پايگاه داده داد، مي‌توان از نمايه‌ها (Views) استفاده كرد كه عملكردي مشابه با پايگاه‌داده رابطه‌اي دارند. در كوچ‌، هر View را يك فانكشن جاوااسكريپت مي‌سازد (تعجب نكنيد‌، درست خوانديد، جاوااسكريپت سمت سرور) كه به‌عنوان نقشه نگاشت اين عمليات خواهد بود. اين تابع يك سند را به‌عنوان ورودي دريافت مي‌كند و يك متغير را به‌عنوان خروجي پس مي‌دهد. منطق تابع جاوااسكريپت شما كمابيش پيچيده خواهد شد.
    همانطور كه خودتان هم حدس زده‌ايد، چنين تابعي مي‌تواند هزينه سنگيني روي دوش ديتابيس بگذارد. ديتابيس كوچ مي‌تواند اين نمايه‌ها را شاخص‌بندي (ایندکس) كرده و هنگام به‌روزآوري، ايجاد يا حذف ركوردها، اين نمايه‌ها را هم به‌روز كند. با اين مكانيزم شاخص‌بندي، سرور دچار كندي نمي‌شود.

    معماري توزيعي و همتاسازي
    طراحي اوليه كوچ‌ را با در نظر گرفتن همتاسازي 2طرفه (همخوان‌سازي يا Synchronization) و عمليات آفلاين انجام داده‌اند. اين يعني هر بخش مي‌تواند داده خود را داشته باشد، آن را ويرايش كند و بعد اين تغييرات را همخوان كند.

    Erlang
    همانند ديگر ديتابيس‌هاي توزيعي هم‌نسل كوچ، اين ديتابيس را هم به‌زبان Erlang نوشته‌اند و از پلت‌فرمErlang OTP استفاده مي‌كند. ارلنگ زباني است كه براي سيستم‌هاي مخابراتي سريع و پايدار استفاده مي‌شد، اما برنامه‌نويسان آن را برنامه‌ جالبي براي پياده‌سازي سرويس‌هاي شبكه يافته‌اند. ارلنگ داده‌ها و فرآيندهاي سبك را كه از انتقال پيام براي اتصالات استفاده مي‌كنند، جدا مي‌كند. ضمن آن‌كه پلت‌فرم OTP راهكارهايي براي ايجاد سيستم‌هاي توزيع‌شده، بي‌درنگ و با دسترسي بالا در اختيار مي‌گذارد. با توجه به رشد سرويس‌هاي شبكه‌اي، بهره بردن از اين پلت‌فرم و اين زبان، يك امتياز براي كوچ به‌حساب مي‌آيد.


    رابط كاربري تحت وبفوتون
    بعد از اين‌كه كوچ را نصب و راه‌اندازي كرديد، مي‌توانيد با مراجعه به آدرس زير، رابط كاربري اين پايگاه داده را مشاهده كنيد:‌


    نام اين رابط كاربري فوتون است و براي چك كردن داده‌ها و انجام عمليات ساده‌اي همچون ايجاد ديتابيس، حذف ديتابيس، مديريت سندها و ... كاربرد دارد.
    براي اطلاعات بيشتر در مورد اين پايگاه داده، به آدرس‌هاي زير رجوع كنيد:

    يکي ديگر از ويژگي‌هاي CouchDB و در كل ديتابيس‌هاي NoSQL، ارتقاپذيري بهتر آن‌ها نسبت به پايگاه‌هاي داده‌اي قديمي‌تر است. ارتقاي ديتابيس در سيستم‌هاي SQL به‌منظور ارتقاي ساختار (Schema) و داده‌ها است که امکان رخ دادن خطا در آن زياد مي‌شود. در صورتي که در ديتابيس‌هاي سندگرا، اسکيمايي وجود ندارد و داده‌هاي جديد در کنار داده‌هاي قديمي قرار مي‌گيرند و نيازي به‌تغيير ساختار وجود ندارد.

    نتیجه گیری در پايان، همان پاسخ اوليه را تكرار مي‌كنيم كه نبايد NoSQL را به‌عنوان نسل بعدي و جايگزين همين سيستم‌هاي معمولي دانست و بگوييم مثلا NoSQL از پايگاه‌هاي رابطه‌اي بهتر است. پرسش اين است كه چه زمان بايد از NoSQL استفاده كرد؟

    اينجاست كه بايد كلاه خود را قاضي كنيد و به اندازه سيستم، ميزان رشد سيستم و تراكنش‌هايي كه در سيستم رخ مي‌دهند توجه نشان دهيد.

    بايد توجه كنيد كه مثلا راه‌اندازي يك سرويس بلاگ كه در هر ثانيه چندين مطلب به آن اضافه مي‌شود و ... حتما يك پايگاه رابطه‌اي را به زانو در مي‌آورد، در صورتي كه اين داده‌ها در NoSQL‌ قرار بگيرند (كه مخصوص اين كار درست شده است) مي‌توانند بازدهي بسيار خوبي داشته باشند.

    منبع: پی سی پدیا
    ویرایش توسط admin : Monday 20 May 2013 در ساعت 01:42 PM

  • The Following User Says Thank You to admin For This Useful Post:

    miss.ahoor (Sunday 28 July 2013)

  • #3
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,820
    Thanks
    22
    Thanked 47 Times in 42 Posts

    Post آیا می‌دانید Database آمازون، گوگل، LinkedIn، تویتر و یا فیس بوک چیست؟



    جواب سوال NoSQL است. حالا NoSQL چیست؟ و چرا به آن ممکن است نیاز پیدا کنید؟
    NoSQL مخفف Not only SQL است. و علت نام گذاری آن القای مفهموم Not use SQL برای تغییر داده ها است.
    NoSQL یک راه جدید فکر کردن راجع به Database است. NoSQL یک Database رابطه‌ای (RDBMS) نیست و حقیقت این است که Database رابطه‌ای همیشه یک انتخاب مناسبت نیست.
    فکر کنید که شما یک نوع داده خاص را از کاربر می‌خواهد که قبلا آن را تصور نکرده اید و هیچ گونه Schema یا مدلی برای آن ایجاد نکرده اید.آیا ملزم کردن شما به تعریف یک طرح یا "schema" محدود کردن شما نیست؟ آیا می‌خواهید داده ای را ثبت کنید که قبلا آن را در نظر نداشته اید؟ تغییر سریع رفتار application شما نیازمند تغییر در فورمت داده ها، محتوا و اساس برنامه دارد؟ با تکنولوژی RDBMS تغییرات اینچنینی بسیار برهم زننده و سخت است و معمولا از اعمال آنها اجتناب می‌شود. سیستمی را تصور کنید که یک پویایی بی نهایت بخواهد. Database رابطه ای قدیم یک نوع داده از قبل پیش بینی شده و ساختار یافته را نیاز دارد. این نوع database سرورهایی نیاز دارند که به مرور با بزرگتر شدن حجم داده‌ها برای پردازش آنها باید گسترش یابند. البته برای حل مشکلاتی که در تکنولوژی RDBMS بیان شد برنامه نویسان راهکارهای ارائه داده اند که عبارتند از:

    1) Sharding
    2) Denormalizing
    3) Distributed Caching

    یک راه به اصطلاح cloud-friendly دیگر وجود دارد که آن به کارگیری NoSQL است.
    این نوع Database جدول یا Table ای ندارد و از SQL برای تغییر داده ها استفاده نمی کند، همچنین ممکن است از ACID پشتیبانی نکند. (Atomicity,Consistency, Isolation, Durability) اما کماکان قابلیت distributed شدن و fault tolerant (تحمل خطا) را دارد.

    مقایسه نرم افزارهای چند دهه قبل و حالا
    وب اپلیکیشن های مدرن کنونی می‌توانند از میلیون ها کاربر پشتیبانی کنند، و این load را روی application server ها تقسیم می‌کنند. همانطور که در شکل زیر می‌بینید، تفاوت‌های بنیادین بین کاربران برنامه ها و زیربنای نرم افزارهای سیستمی سال 1970 و آنهایی که اکنون ساخته می‌شوند می‌بینید.
    معماری دیتابیس تغییر زیادی نداشته است.



    وب اپلیکیشن‌های مدرن مقایس بسیار بزرگی دارند، با قرار دادن وب سرورهای بیشتر پشت load balancer می توان از کاربران بیشتری پشتیبانی کرد. تکنولوژی relational database یا دیتابیس رابطه ای (RDBMS) به صورت بنیادین تغییری در چهل سال اخیر نداشته است، و به عنوان انتخاب اولیه برای ذخیره داده ها بسیاری از وب اپلیکیشن ها و سیستم های نرم افزاری باقی مانده است. پشتیبانی از کاربران بیشتر به معنی اضافه کردن سرورهای بزرگتر (در شکل زیر) است. سرورهای بزرگتر معایب زیادی دارند که از جمله پیچیدگی آنها، خصوصی سازی و هزینه بسیار بالای آنها را می‌توان نام برد.


    گوگل و آمازون پیشروان ابداع، توسعه و وابستگی به تکنولوژی دیتابیس مختص به خودشان هستند. در حالی که پیاده سازی NoSQL کاملا متفاوت است، این دیتابیس یکسری ویژگی های خاصی ارائه می دهد:

    1) نیازی به تعریف Schema یا طرح خاصی برای دیتابیس نیست. داده ها می توانند در NoSQL DB بدون نیاز به تعریف الگوی محدود کننده ی خاصی ذخیره شوند. فورمت یا قالب داده‌های که در دیتابیس ذخیره می‌شوند بدون ایجاد آشفتگی در برنامه می‌توانند هر لحظه تغییر کند. در واقع این ویژگی انحطاف پذیریه بینهایتی به application می‌دهد که اساس و نیاز هر bussiness ای است.

    2) Auto-Sharding که بعضا "elasticity" هم خوانده می‌شود. دیتابیس NoSQL (به عنوان دیتابیس بدون مقیاس هم شناخته می‌شود) به صورت خودکار داده ها را بدون نیاز به دخالت برنامه روی سرور می برد. سرور بدون نیاز به پایین آوردن برنامه می‌تواند به لایه داده اضافه یا حذف شود. اکثر دیتابیس های NoSQL از data replication (کپی کردن داده‌ها)، ذخیره کردن چندین نسخه کپی از دیتابیس در cluster و حتی در data center ها، برای اطمینان حاصل کردن از نرخ دردسترس بودن بالا و بازیابی داده، پشتیبانی می‌کنند.

    3) پشتیبانی از Distributed Query: دیتابیس NoSQL قدرت query گرفتن از صدها یا هزاران سرور distributed را دارد.

    4) Integrated caching: برای کاهش زمان تاخیر و افزایش بهره وری سیستم، تکنولوژی دیتابیس های پیشرفته NoSQL قابلیت cache کردن داده ها را در memory سیستم دارند. این قابلیت به صورت transparent یا غیر قابل لمس انجام می‌شود، در مقابل در تکنولوژی Cache, RDBMS کردن داده ها معمولا یک زیرساختار متفاوتی میطلبد که باید جداگانه توسعه داده شود.

    چالش همزمانی داده‌های Device های Mobile:

    درحالی که وب اپلیکیشن ها بیش از ده سال است که درگیر نحوه مدیریت داده ها هستند، در سال‌های اخیر mobile application ها از محبوبیت خاصی برخوردار شده اند. این app های موبایل بر روی device ها نصب می‌شوند و معمولا داده‌هایشان را روی همان device بدون توجه به اینکه به اینترنت وصل هستند یا نه ذخیره می‌کنند. برخلاف داده‌های وب اپلیکیشن ها، این سیستم ها نیازی ندارند تا از صدها یا هزاران کاربر به صورت همزمان پشتیبانی کنند بنابراین به auto-sharding یا distributed quer و یا caching نیازی ندارند.

    از طرف دیگر این سیستم‌ها چالش همزمانی داده‌ها را مطرح می‌کنند، چون موبایل‌ها می‌توانند به راحتی آسیب ببینند یا حتی گم شوند، یه راه حل قابل اعتماد برای backup گیری داده‌ها نیاز است. بسیاری از mobile application ها برادری دیگر نیزدارند (web application ها) :)
    برای مدیریت یک سیستم قوی قطعا یک app موبایل یک وب اپلیکیشن هم دارد. وقتی از دستگاه موبایل خود استفاده می‌کنید، کاربر تغییراتی را در داده‌های local (داخلی) ایجاد می‌کنند و وقتی که به اینترنت متصل می‌شوند، داده ها باید با وب اپلیکیشن برای اطمینان از یکپارچگی داده‌ها synchronize یا همزمان شود.
    تعدادی از دیتابیس‌هایی NoSQL از همزمانی داده‌های بین موبایل و database cluster که در دیتاسنترها یا در cloud توسعه داده شده پشتیبانی می‌کنند.

    مجله ComputerWorld در San Francisco در مقاله ای از NoSQL نوشت: " NoSQLers آمده اند تا به سلطه‌ی کندی و هزینه بار بودن Database رابطه‌ای در مدیریت داده‌ها پایان دهد." این مجله نوشت به خصوص در کسب و کارها Web 2.0 شرکت ها و سازمان ها کسب و کار خودشان را بدون Oracle و حتی MySQL که از شهرت بالایی برخوردار هستند راه اندازی می‌کنند، در عوض آنها Database شان را با الهام از Database آمازون (Dynamo) و Google که تکنینک Bigtable است به منظور ذخیره سازی و پردازش حجم عظیم داده‌ها، شبیه آنچه شما در شبکه های اجتماعی یا اپلیکیشن های Cloud Computing می‌بینید ایجاد می‌کنند. Cassandra یک نوع Database NoSQL است که از base توسط Facebook ایجاد شد و هم اکنون جزو پروژه Apache می‌باشد. طبق گفته Avinash Lakshman این Database در دیتابیس بزرگ 50 گیگابایتی 2500 بار سریع تر از MySQL است.(الان خیلی متعجبید؟)
    اغلب NoSQL Database بر طبق راه و روشی که داده‌ها را ذخیره می‌کنند دسته بندی می‌شوند، و به دسته های key-value stores، Comumn Oriented Database, document sotre و graph database طبقه بندی می‌شوند.



    1) Key-Value: طراحی و پیاده سازی ساده‌ای دارد، به ازای هر کلید این پیاده سازی به کاربر اجازه می‌دهد یک مقدار دریافت کند. ذخیره سازی مدرن key-value مقیاس پذیری و جامعیت بالایی می‌دهد. معمولا طول کلیدهای که ذخیره می‌شوند به چند بایت محدود می‌شوند در حالی که شما محدودیت کمتری در مقابل ذخیره سازی مقدار دارید.
    Key-Value مدت‌های زیادی است که موجود است، اما شهرت اخیر آن تحت تاثیر دیتابیس Amazon با نام Dynamo است. Amazon Dynamo یکی از چندین Database ای است که آمازون برای اهدافش استفاده می‌کند.

    2) Document Database: این نوع Database یک گام فراتر از key-value است و برای اهداف پیچیده تر به کار می‌رود. Document Database ساختاری شبیه به key-value دارد با این تفاوت که به شما اجازه می‌دهد که جفت key-value را در یک encapsulate, Document کنید. از طرفی توجه داشته باشید که هیچ schema خاصی به شما تحمیل نمی‌شود. Apache CouchDB و MongoDB از این نوع هستند.
    CouchDB یک Document Database است که با زبان برنامه نویسی Erlang نوشته شده است. اخیرا CouchDB را مخفف Cluster of unreliable commodity hardware می‌دانند. بیشترین استفاده قابل توجه CouchDB در cloud storage و replication service برای Ubuntu Linux است، همچنین در platform بی بی سی و بلاگ‌ها و wiki و social network ها و بعضی از appهای facebook به کار گرفته شده است.

    3) Column-Oriented Database: این نوع Database از column به جای row برای ذخیره کردن و پردازش داده ها استفاده می‌کند. بهترین نمونه برای مثال زدن از Google's Bigtable, column-oriented datastor است.
    3-1) Google's Bigtable: از Bigtable به عنوان " یک storage system توزیع شده برای مدیریت داده‌های ساخت یافته در مقیاس بسیار بزرگ (داده‌های در مقیاس petabyte در هزاران سرور)" یاد می‌شود. Bigtable در پنج پروژه بزرگ گوگول در سال 2006 استفاده شد، این پروژه ها شامل Orkut, Google Analytics, Google Earth, web Indexing و Google Docs می باشند (پروژه‌های بسیار قوی). تجربه نشان داده است که گوگل از Bigtable برای رسید به این اهداف استفاده می‌کند.

    1) کاربرد بسیار وسیع
    2)مقایس پذیری بالا
    3) performance بالا

    3-2) Cassandra: این Database از اساس توسط Facebook در سال 2008 ایجاد شده است. Cassandra به عنوان " storage توزیع شده برای مدیریت داده‌های ساخت یافته که برای مقایس‌های بسیار بزرگ طراحی شده اند" یاد می‌شود. در کنار Facebook شرکت‌های بزرگ دیگری نظیر Twitter, Digg و Rackspace از این نوع Database استفاده می‌کنند. پردازش حجیم داده‌ها از ویژگی های بارز این Database است (100 میلیون کاربر در June 2008 به 250 میلیون در August 2009 و به بیش از 600 بیلیون کاربر در January 2011 در فیسبوک افزایش یافت.)

    نویسنده : علی طهرانی
    منبع:virtualseason.ir

  • The Following User Says Thank You to admin For This Useful Post:

    miss.ahoor (Sunday 28 July 2013)

  • #4
    سردبير بخش اخبار و تازه هاي كامپيوتر Array Sardabir آواتار ها
    تاریخ عضویت
    Monday 3 October 2005
    نوشته ها
    3,787
    Thanks
    81
    Thanked 50 Times in 45 Posts

    Exclamation منابع NoSQL

    عنوان کتاب : Cassandra High Performance Cookbook
    نویسنده : Edward Capriolo



    http://www.packtpub.com/cassandra-ap...-cookbook/book

    عنوان کتاب : CouchDB: The Definitive Guide: Time to Relax (Animal Guide)

    نویسنده : J. Chris Anderson, Jan Lehnardt, Noah Slater



    http://www.amazon.com/CouchDB-Defini...dp/0596155891/
    http://oreilly.com/catalog/9780596155896/

    عنوان کتاب : Beginning CouchDB

    نویسنده : Joe Lennon



    http://www.amazon.com/Beginning-Couc...dp/1430272376/

    عنوان کتاب : Scaling CouchDB

    نویسنده : Bradley Holt



    http://oreilly.com/catalog/9781449303433/

    عنوان کتاب : Writing and Querying MapReduce Views in CouchDB

    نویسنده : Bradley Holt



    http://oreilly.com/catalog/0636920018247/

    عنوان کتاب : Hadoop: The Definitive Guide

    نویسنده : Tom White



    http://www.amazon.com/Hadoop-Definit...dp/1449389732/

    عنوان کتاب : Pro Hadoop

    نویسنده : Jason Venner



    http://www.amazon.com/Pro-Hadoop-Jas...dp/1430219424/

    عنوان کتاب : Hadoop in Action

    نویسنده : Chuck Lam



    http://www.amazon.com/Hadoop-Action-...dp/1935182196/

    عنوان کتاب : HBase: The Definitive Guide

    نویسنده : Lars George



    http://www.amazon.com/HBase-Definiti...dp/1449396100/


  • #5
    مدير انجمن کاریابی Array itjobs آواتار ها
    تاریخ عضویت
    Saturday 24 February 2007
    نوشته ها
    6,116
    Thanks
    59
    Thanked 58 Times in 53 Posts

    پیش فرض

    واژه‌نامه پایگاه‌های داده NoSQL

    ماهنامه شبکه - خرداد 1391 شماره 133



    اشاره: ماهنامه شبکه - NoSQL مفهومي جديد در پايگاه‌ داده‌ها است و طبيعي است كه به همراه خود واژه‌ها و كلمات جديدي را نيز به فهرست لغات بانك‌هاي اطلاعاتي و برنامه‌نويسي اضافه كنيد. در ادامه مي‌توانيد با مهم‌ترين واژه‌ها و كلمات كليدي پرونده ويژه NoSQL آشنا شويد.

    اين مطلب يكي از مقالات بخش ويژه نشريه ماهنامه شبكه در شماره 133 با عنوان جنبش NoSQL مي‌باشد. جهت دريافت اين بخش ويژه به بخش پرونده‌هاي ويژه سايت مراجعه نمائيد. Bigtable (جدول بزرگ) جدول‌بزرگ یا Bigtable یک پایگاه‌داده توزیع‌شده است که در سال 2006 به عنوان یک پایگاه داده ستونی بر مبنای سیستم فایلی گوگل (GFS) ساخته شده است. Bigtable و دایناموی آمازون والدین مستقیم کاساندرا هستند. کاساندرا خصوصیات آرایه‌های داده‌ای پراکنده و ذخیره‌سازی روی دیسک با استفاده از SSTable را از این پایگاه‌داده به ارث برده است. پایگاه‌داده HBace یاهو یک بازسازی (کلون) از Bigtable است. مقاله کامل گوگل درباره Bigtable را می‌توانید در آدرس زیر بخوانید:
    http://lab.google.com/papers/bigtable.html Cassandra (کاساندرا) در افسانه‌های یونان، کاساندرا دختر شاه پِریام و ملکه هِکوبا از خانواده سلطنتی تروا بود. او به حدی زیبا بود که آپولو قدرت دیدن آینده را به او عطا کرد. اما زمانی که او این لطف عاشقانه را نپذیرفت، آپولو او را نفرین کرد تا هرچه در آینده رخ خواهد داد را به دقت پیش‌بینی کند، اما هیچ کس حرف‌های او را باور نکند. او ویرانی شهرش تروا را دید، اما توان مقابله با این اتفاق را نداشت... نام این پایگاه‌داده توزیع‌شده، از روی همین افسانه انتخاب شده است. این انبار داده یکی از پروژه‌های بنیاد آپاچی است که در آدرس http://cassandra.apache.org در دسترس است. مراحل اولیه شکل‌گیری آن در ژانویه 2009 طی شد. از خصوصیات کلیدی این پایگاه‌داده می‌توان به عدم تمرکز، الاستیک بودن، قابلیت تحمل خطا، ثبات قابل تنظیم، بهینه‌سازی و دسترس‌پذیری بالا اشاره کرد. همچنین این پایگاه‌داده از ابتدا به گونه‌ای طراحی شده است که به شدت مقیاس‌پذیر بوده و به‌سادگی روی سرورهای معمولی که در دیتا‌سنترهای مختلف پراکنده شده‌اند، توزیع شود. شرکت‌هایی مانند Digg، فیس‌بوک، Cloudkick، سیسکو، آی‌بی‌ام، Reddit، Rackspace، SimpleGeo، Ooyala و OpenX از این پایگاه‌داده استفاده می‌کنند. Cluster (خوشه، کلاستر) به دو یا چند نسخه (Instance) از کاساندرا که در هماهنگی با یکدیگر کار می‌کنند، خوشه گفته می‌شود. این نسخه‌ها به کمک Gossip با یکدیگر ارتباط برقرار می‌کنند. وقتی شما یک نود جدید را برای معرفی به کلاستر موردنظرتان پیکر‌بندی می‌کنید، باید چند کار کوچک انجام دهید. ابتدا باید یک نود Seed معرفی کنید. پس از آن باید پورت‌هایی را تعریف کنید که کاساندرا باید برای ارتباط با Gossip و Thrift به آن‌ها گوش دهد. پس از این‌که کلاستر شما پیکربندی شد، باید از ابزار Node Tool برای کنترل صحت تنظیمات استفاده کنید. Column (ستون) ستون، ابتدایی‌ترین واحد ارائه اطلاعات در مدل‌داده‌ای کاساندرا است. یک ستون ترکیبی سه‌گانه از یک نام (که گاهی کلید یا key نامیده می‌شود)، یک مقدار و یک برچسب زمانی است. مقادیر یک ستون به همراه برچسب زمانی آن توسط کلاینت پایگاه داده فراهم می‌شود. نوع داده کلید و مقدار، هر دو آرایه‌های بایتی جاوا (Java Byte Array) است. نوع داده برچسب زمانی یک نوع طولانی (Long) اولیه است. برای جلوگیری از بروز مشکل در حالت چندرشته‌ای، ستون‌ها به صورت غیرقابل‌تغییر (Immutable) تعریف شده‌اند. ستون‌ها در خانواده‌های ستون (Column Families) دسته‌بندی می‌شوند. Consistency (ثبات) ثبات به این معنا است که یک تراکنش هیچ‌گاه پایگاه داده را در یک حالت ناپایدار یا غیرمجاز ترک نخواهد کرد و همچنین هیچ یک از قیدهای یکپارچگی نقض نخواهند شد. این مورد به یکی از جنبه‌های حیاتی تراکنش‌ها در پایگاه‌های داده رابطه‌ای و یکی از خصوصیات ACID (سرنام Atomic, Consistent, Isolated, Durable به معنی اتمیک، پایدار، ایزوله شده و دارای ماندگاری) اشاره می‌کند. در کاساندرا درجه نسبی پایداری براساس موارد زیر محاسبه می‌شود:
    - N تعداد نودهایی است که کپی‌های یک داده را نگه‌داری می‌کنند.
    - W تعداد نودهایی که باید دریافت صحیح داده را تأیید کنند.
    - R تعداد کپی‌هایی که در هنگام دسترسی به یک شیء داده در عملیات خواندن اطلاعات، با آن‌ها تماس برقرار می‌شود.
    - در این صورت اگر R+W از N بزرگتر باشد، ثبات بالایی خواهیم داشت و در غیر این صورت ثبات مشروط خواهد بود. Decentralized (تمرکز زدایی شده) کاساندرا به عنوان یک پایگاه داده تمرکززدایی شده در نظر گرفته می‌شود چرا که هیچ سرور مرکزی‌ای تعریف نمی‌کند و درعوض از یک رویکرد نظیر به نظیر استفاده می‌کند تا از بروز گلوگاه و ایجاد یک نقطه شکست مرکزی جلوگیری کند. تمرکززدایی در کاساندرا بسیار حیاتی به شمار می‌آید، زیرا امکان افزایش مقیاس یا کاهش آن را برای کاساندرا فراهم می‌کند. نودها می‌توانند به دلخواه به شبکه افزوده شده یا از شبکه بیرون روند و این امر کمترین تأثیری در کل پایگاه داده نداشته باشد. Denormalization (غیرنرمال سازي ) در پایگاه‌های داده رابطه‌ای، غیرنرمال سازی یا ایجاد داده‌های اضافی، فرآیندی است که برای بهبود کارایی برنامه‌هایی که بیشتر با عملیات خواندن داده‌ها سروکار دارند، انجام می‌پذیرد. پردازش تحلیلی آنلاین OLAP (سرنام OnLine Analytical Processing) از جمله این فرآیندها است. در کاساندرا دیدن داده‌های غیرنرمال شده بسیار طبیعی است؛ چرا که این کار باعث افزایش کارایی شده و کمک می‌کند که داده‌ها براساس پرس‌وجوهای موردنیاز ساختاردهی شوند. این درست نقطه مقابل پایگاه‌های‌داده سنتی رابطه‌ای است که به صورت مستقل برپایه مدل شیء (Object Model) ساختاردهی می‌شوند. Dynamo (داینامو) این سیستم که در سال 2006 توسط آمازون و همزمان با Bigtable گوگل ایجاد شده است، یکی از پایه‌های کاساندرا است. کاساندرا با استفاده از داینامو به یک انبار داده‌های کلید-مقدار، یک معماری نظیر به نظیر متقارن، کشف داده گمان محور (gossip-based discovery) و ثبات مشروط دست می‌یابد. شما می‌توانید مقاله «داینامو: انبار کلید-مقدار کاملاً دردسترس آمازون» را در آدرس زیر بیابید:
    http://www.allthingsdidtributed.com/...ns_dynamo.html Elastic (کشسانی، الاستیک) میزان عملیات خواندن و نوشتن داده‌ها با افزودن ماشین‌های بیشتر به کلاستر به صورت خطی افزایش می‌یابد. تحمل خطا یا Fault Tolerance توانایی ادامه کار حتی در صورت خرابی یک یا چند بخش سیستم است. از این توانایی گاهی با نام تنزل مطبوع یا graceful Degradation نیز نام برده می‌شود و به این معنا است که اگر کارایی سیستم در اثر بروز خطا تنزل پیدا کرد، کاهش کارایی تنها متناسب با بخش از کار افتاده باشد. Hector (هکتور) پروژه اپن‌سورسی است که توسط ران تاوری (Ran tavory) پایه‌گذاری شده و روی Github میزبانی می‌شود. هکتور، کلاینتی برای کاساندرا است که به وسیله جاوا نوشته شده است. این پروژه Thrift را پوشانده (wrap کرده) و می‌تواند قابلیت‌های JMX،Connection Pooler و Fail over را ارائه کند. Memtable (جدول حافظه) به نسخه‌ای از داده‌ها که به تازگی در جدولی در حافظه نوشته شده باشد، اطلاق می‌شود. هنگامی که این جدول پر شود به صورت یک SSTable روی دیسک ذخیره خواهد شد. Node (گره یا نود) یک نسخه درحال اجرا از کاساندرا را یک نود می‌گویند. کلاسترهای کاساندرا به صورت معمول تعداد زیادی نود دارند و به همین دلیل گاهی حلقه نودها یا به تنهایی «حلقه» نامیده می‌شوند. اصطلاح نود به هر سروری در کلاستر کاساندرا اشاره می‌کند، در صورتی که «رپلیکا» (Replica) به نودی اشاره می‌کند که یک کپی از برخی داده‌های یک نود دیگر را در خود داشته باشد. NoSQL اصطلاح NoSQL نامی عمومی است که به مجموعه‌ای از پایگاه‌های داده اطلاق می‌شود که از زبان پرس‌وجوی ساخت‌یافته SQL (سرنام Structured Query Language) یا مدل داده رابطه‌ای استفاده نمی‌کنند. گاهی این اصطلاح را مخفف Not Only SQL می‌دانند تا تأکید کنند که طرفداران انواع پایگاه‌های داده غیررابطه‌ای معتقدند که پایگاه‌های داده رابطه‌ای سنتی تنها راه موجود برای ذخیره‌سازی داده نیستند، اما این به آن معنا نیست که به خودی خود انتخاب نادرستی باشند. این اصطلاح نخستین‌بار توسط اریک اوانس از Rackspace به کار رفت. او که یکی از توسعه‌دهندگان کاساندرا است، پس از آن از به کار بردن این اصطلاح خودداری می‌کند و به جای آن مایل است اصطلاح BigData یا داده‌های عظیم را به کار ببرد تا این گروه از پایگاه‌های داده را نه بر‌اساس چیزی که نیستند (سازگار با SQL) بلکه بر‌اساس کاری که می‌کنند (مدیریت مقادیر عظیم داده) تعریف کند. دوره استفاده از این اصطلاح کم‌وبیش به پایان رسیده است چرا که بسیار گیج‌کننده است و به نظر می‌رسد باعث می‌شود راجع به مجموعه‌ای از پایگاه‌های داده بحث کنیم که در عمل میزان شباهت میان اهداف، ایده‌های طراحی و قابلیت‌های آن‌ها بسیار اندک است. بهتر است بگذاریم کاساندرا همان کاساندرا، CouchDB همان CouchDB و Riak همان Riak بماند. Partition (پارتیشن) به صورت کلی، پارتیشن به یک بخش مجزا از شبکه اشاره می‌کند. این جداسازی بخش‌ها در اثر یک شکست یا قطعی در شبکه ایجاد شده و باعث می‌شود یک ماشین نتواند به صورت مستقیم با یک ماشین دیگر تماس برقرار کند. پارتیشن ممکن است در اثر خرابی یک سوییچ، روتر یا رابط‌های شبکه به‌وجود آید. کلاستری از 5 ماشین {A,B,C,D,E} را تصور کنید که در آن {A,B} روی یک زیرشبکه یا Subnet و {C,D,E} روی زیرشبکه دیگری باشند. اگر سوییچی که به گروه دوم متصل است از کار بیافتد، شما پارتیشنی خواهید داشت که این دو زیرگروه را از هم جدا خواهد کرد. کاساندرا پایگاه‌داده‌ای است که قابلیت تحمل خطاها را دارد و پارتیشن‌های شبکه یکی از این خطاها هستند. به همین دلیل کاساندرا می‌تواند در صورت مواجه شدن با یک پارتیشن به کار خود ادامه دهد و داده‌ها را پس از برطرف شدن مشکل پارتیشن، دوباره با هم ادغام کند. Replication (تکثیر) به صورت کلی در سیستم‌های توزیع‌شده، اصطلاح تکثیر به ذخیره چندین کپی از داده روی چندین ماشین مختلف اطلاق می‌شود. این امر به این دلیل انجام می‌شود که در صورت خرابی یکی از ماشین‌ها یا عدم امکان دسترسی به آن در صورت ایجاد یک پارتیشن، کلاستر هنوز بتواند به داده‌ها دسترسی داشته باشد. کش کردن داده‌ها (Caching) یکی از ساده‌ترین راه‌های تکثیر است. در کاساندرا، تکثیر ابزاری برای فراهم‌آوردن کارایی بالا، دسترس‌پذیری و قابلیت تحمل خطا است. Row (سطر) در یک خانواده ستون، یک سطر نقشه‌ای مرتب‌شده است که نام ستون‌ها را با مقادیر آن‌ها انطباق می‌دهد. در یک ابرستون (Super Column) یک سطر، نقشه‌ای مرتب‌شده است که اسامی ابرستون را با نقشه ارتباطی اسم ستون و مقدار ستون متناظر آن پیوند می‌دهد. Thrift نام یک کلاینت فراخوانی راه‌دور پردازه(RPC سرنام Remote Procedure Call) است که برای ارتباط با سرور کاساندرا مورد استفاده قرار می‌گیرد. این کلاینت به صورت استاتیک رابطی برای سریال‌سازی را در بسیاری از زبان‌ها از جمله ++C، جاوا، پایتون، پی‌اچ‌پی، روبی، ارلنگ، پرل، هسکل، سی‌شارپ، کاکائو، اسما‌ل‌تاک و OCaml فراهم می‌کند. همین مکانیسم است که به شما اجازه می‌دهد از طریق تمام این زبان‌ها با کاساندرا ارتباط برقرار کنید. در زمان نوشتن این مطلب احتمال زیادی وجود دارد که پروژه‌ای جدیدتر و فعال‌تر از آپاچی به نام آورو (Avro) جایگزین رابط Thrift شود. یکی از مزیت‌های مهم آورو این است که به ایجاد کدهای استاتیک احتیاجی ندارد. Hadoop (هادوپ) هادوپ یک فریم‌ورک نرم‌افزاری است که کاربردهای توزیع‌شده با داده‌های فراوان را تحت یک مجوز آزاد، پشتیبانی می‌کند. این فریم‌ورک به برنامه‌ها امکان می‌دهد که با هزاران نود و داده‌هایی در اندازه‌های پتابایت کار کنند. هادوپ از مقالات مرتبط با سیستم Map Reduce گوگل و همچنین سیستم فایلی آن GFS، الهام گرفته است. HDFS یک سیستم‌فایلی توزیع‌شده، مقیاس‌پذیر و قابل حمل (portable) است که با زبان جاوا برای هادوپ نوشته شده است. این سیستم‌فایلی برای ارتباطات از لایه TCP/IP استفاده می‌کند و کلاینت‌های آن از RPC برای ارتباط با یکدیگر بهره می‌برند. سیستم‌فایلی HDFS فایل‌های بزرگ (اندازه ایده‌آل فایل‌ها مضارب 64 مگابایت است) را در ماشین‌های مختلف ذخیره می‌کند. این سیستم برای افزایش قابلیت اعتماد، داده‌ها را در میزبان‌های مختلفی تکثیر می‌کند و به همین دلیل به قابلیت RAID روی میزبان‌ها احتیاجی ندارد. با مقدار پیش‌فرض تکثیر 3، داده‌ها روی سه نود ذخیره می‌شوند که از این سه نود، دو نود در یک رک و یکی در رک دیگری واقع شده است. HBase پایگاه داده هادوپ برای دسترسی خواندن و نوشتن تصادفی است. HBase پایگاه داده توزیع‌شده، غیر رابطه‌ای و اپن‌سورس است که از روی BigTable گوگل مدل‌سازی و به وسیله جاوا نوشته شده است. این پایگاه داده به عنوان جزئی از پروژه هادوپ در بنیاد نرم‌افزار آپاچی توسعه داده شده است و روی HDFS اجرا می‌شود و قابلیت‌هایی همانند BigTable را برای هادوپ به ارمغان می‌آورد. به این معنا که امکان ذخیره‌سازی حجم عظیمی از داده‌های پراکنده را به روشی که تحمل خطا را نیز دارد، فراهم می‌کند. پایگاه داده HBase قابلیت‌های فشرده‌سازی، اجرای عملیات داخل حافظه و فیلترهای انفجاری به صورتی ستون محور را؛ درست همان‌گونه که مقاله اصلی BigTable تشریح کرده است، فراهم می‌کند. جدول‌‌های HBase می‌توانند به عنوان ورودی و خروجی عملیات Map Reduce که روی هادوپ در حال اجرا هستند به کار برده شوند. از طریق APIهای جاوا، REST، آورو و یا گیت‌وی‌های Thrift می‌توان به این جدول‌ها دسترسی پیدا کرد. Hive (هایو) پرس‌وجوها و جداول شبه SQL که روی مجموعه‌های عظیم داده عمل می‌کنند. هایو آپاچی یک زیرساخت برای انبارهای داده (data warehouse infrastructure) است که بر مبنای هادوپ و برای خلاصه‌سازی، پرس‌وجو و تحلیل داده‌ها ساخته شده است. اگرچه در ابتدا توسط یکی از شبکه‌های اجتماعی مشهور توسعه داده شده، اما اکنون به عنوان یک پروژه آپاچی در سایر شرکت‌ها نظیر نت‌فلیکس هم مورد استفاده قرار می‌گیرد. هایو اکنون در Amazon Elastic Map Reduce که از سرویس‌های آمازون است به کار می‌رود. هایو امکان تحلیل مجموعه‌های عظیم داده که روی سیستم‌های‌فایلی سازگار با هادوپ؛ نظیر S3 آمازون، ذخیره شده‌اند را فراهم می‌آورد. هایو در عین پشتیبانی کامل از Map Reduce، زبانی شبیه به SQL با نام HiveQL را نیز در اختیار کاربران قرار می‌دهد. هایو برای سریع‌تر کردن پرس‌وجوها از اندیس‌ها؛ از جمله اندیس‌های Bitmap استفاده می‌کند. Pig (پیگ) پیگ پلتفرمی سطح بالا برای ایجاد برنامه‌های Map Reduce روی هادوپ است. زبان مورد استفاده در این پلتفرم پیگ لاتین (Pig Latin) نامیده می‌شود. پیگ لاتین برنامه‌نویس را از کدنویسی Map Reduce براساس جاوا بی‌نیاز کرده و این قابلیت‌ها را به صورت سیستم نگارشی سطح بالایی عرضه می‌کند که بسیار شبیه SQL در سیستم‌های RDBMS است. پیگ لاتین را می‌توان به کمک UDF (سرنام User Defined Functions یا توابع تعریف شده توسط کاربر) گسترش داد که کاربر می‌تواند این توابع را در جاوا پیاده‌سازی کرده و بعدتر مستقیماً از طریق پیگ لاتین فراخوانی کند. پیگ در اصل در سال 2006 در مراکز تحقیقاتی یاهو برای محققان توسعه داده شد تا روشی ساده برای ایجاد و اجرای عملیات Map Reduce روی مجموعه‌های بسیار عظیم داده در اختیار داشته باشند. در سال 2007 این پروژه به بنیاد نرم‌افزاری آپاچی منتقل شد. Oozie (اوزی) نام گردش کاری است که عملیات‌های مختلف هادوپ وابسته به هم، براساس آن انجام می‌شوند. اوزی یک سرویس مختصات‌دهی و گردش کار است که مدیریت عملیات مختلف پردازش داده را به عهده دارد. اوزی سرویسی قابل گسترش، مقیاس‌پذیر و حساس به داده است که می‌تواند نیازها و ارتباطات میان عملیات در حال اجرا روی هادوپ (نظیر HDFS، پیگ و Map Reduce) را هماهنگ کند. اوزی خیلی از کارها را به انجام می‌رساند اما دو کار را نمی‌تواند انجام دهد:
    - فراهم‌آوردن راه‌حلی برای پردازش مستقل از هادوپ
    - فراهم‌کردن یک API جدید برای پردازش پرس‌وجوها Sqoop (اسکوپ) پایگاه‌های داده و انبارهای داده را با هادوپ ادغام می‌کند. پروژه اسکوپ آپاچی ایجاد شده است تا داده‌های حجیم را به صورتی کارا میان هادوپ و سیستم‌های ذخیره‌سازی ساخت‌یافته بیرونی نظیر RDBMS و انباره‌های داده (Data warehouse) جابه‌جا کند، چرا که این پایگاه‌های داده به سادگی از طریق هادوپ قابل دسترسی نیستند. اسکوپ اکنون در حال طی مراحل Incubation (مراحل اولیه پذیرش یک پروژه) در بنیاد نرم‌افزاری آپاچی است. Zookeeper Zookeeper سرویسی برای برنامه‌های توزیع‌شده است. به عبارت دیگر سرویسی مرکزی است که نگه‌داری اطلاعات پیکربندی، نام‌گذاری، فراهم‌آوردن همسان‌سازی توزیع‌شده و همچنین ایجاد سرویس‌های گروهی را بر عهده دارد. تمام این سرویس‌های متفاوت به نوعی در برنامه‌های توزیع‌شده مورد استفاده قرار می‌گیرند. Hue فریم‌ورک و SDK رابط کاربری برای برنامه‌های بصری هادوپ است. Hue هم یک رابط کاربر مبتنی بر وب هادوپ است و هم فریم‌ورکی برای ایجاد برنامه‌های تعاملی وب. این فریم‌ورک شامل یک File Browser برای دسترسی به HDFS، یک برنامه JobSub و JobBrowser برای ایجاد یا مشاهده عملیات Map Reduce و یک برنامه Beeswax برای تعامل با هایو است. علاوه بر همه این‌ها، رابط وبی آن بیشتر بر مبنای ابزارک‌های توصیفی (Declarative Widgets) ساخته شده است که نیازی به جاوااسکریپت ندارد و یادگیری آن بسیار ساده است. Map Reduce یک فریم‌ورک نرم‌افزاری است که در سال 2004 توسط گوگل عرضه شد تا محاسبات توزیع‌شده روی مجموعه عظیمی از داده‌های ذخیره شده روی کلاسترهای کامپیوتری را پشتیبانی کند. برخی از بخش‌های این فریم‌ورک در برخی کشورها به صورت حق اختراع انحصاری (Patent) ثبت شده‌اند. این فریم‌ورک از توابع map و reduce که به صورت معمول در برنامه‌نویسی رویه‌ای مورد استفاده قرار می‌گیرند، الهام گرفته است؛ هرچند که عملکرد آن‌ها در اینجا هیچ شباهتی به فرم اولیه ندارد. کتابخانه‌های Map Reduce به زبان‌های مختلفی از جمله ++C، سی شارپ، ارلنگ، جاوا، LabView، OCaml، پرل، پایتون، پی‌اچ‌پی، روبی، F#، R و سایر زبان‌ها نوشته شده‌اند.

  • #6
    سردبير بخش اخبار و تازه هاي كامپيوتر Array Sardabir آواتار ها
    تاریخ عضویت
    Monday 3 October 2005
    نوشته ها
    3,787
    Thanks
    81
    Thanked 50 Times in 45 Posts

    Post NoSQL به سرعت در حال رشد است



    مونوگو دی‌بی، کمپانی است که نسل جدید فناوری پایگاه داده‌های متن باز یا همان NoSQL را توسعه داده است. در هفته‌‌ی گذشته، این کمپانی ۸۰ میلیون دلار دیگر به سرمایه‌ی خود اضافه کرد.

    براساس اطلاعات ارائه شده توسط کمیسیون بورس و اوراق بهادار ایالات متحده‌ی آمریکا، مونگو دی‌بی، ۸۰ میلیون دلار به سرمایه‌ی خود افزوده است. دِو تیچریا، مدیرعامل این کمپانی اعلام کرد که آن‌ها موفق به جمع‌آوری سرمایه از محل فروش سهام خود شده است. مونگو دی‌بی بسته‌ی سهامی به ارزش ۱۰۰ میلیون دلار را به فروش گذاشته بود که با توجه به گزارش‌های منتشر شده، هنوز سهامی به ارزش ۲۰ میلیون دلار از این کمپانی باقی مانده است. اولین دور از فروش سهام در دهم دسامبر سال ۲۰۱۴ آغاز شده است.

    این اولین باری نیست که مونگو دی‌بی اقدام به جمع‌آوری سرمایه کرده است. پیش از این نیز در سال ۲۰۱۳ این کمپانی موفق به جمع‌آوری ۱۵۰ میلیون دلار شد که بزرگ‌ترین مبلغ تزریق شده به این کمپانی است. با اضافه شدن ۸۰ میلیون دلار دیگر، ارزش این کمپانی به ۱.۲ میلیارد دلار رسید. از جمله‌ی رقبای مونگو دی‌بی می‌توان به اوراکل اشاره کرد.
    مونگو دی‌بی نسل جدید فناوری‌های متن‌باز برای پایگاه داده را ارائه کرده است که ساختار آن برخلاف پایگاه‌ داده‌های رابطه‌ای است. کمپانی‌های بزرگی از این فناوری برای نگه‌داری داده‌ها استفاده می‌کنند.

    منبعtechcrunch

  • #7
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,820
    Thanks
    22
    Thanked 47 Times in 42 Posts

  • #8
    مدیر انجمن ها Array
    تاریخ عضویت
    Friday 20 January 2006
    نوشته ها
    2,237
    Thanks
    7
    Thanked 9 Times in 9 Posts

    Post ابزار جدید برای زبان برنامه‌نویسی SQL عرضه شد




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

    به گزارش ونچربیت، این سیستم برای بیشتر از یک سال به صورت آزمایشی با نام N1QL در اختیار مراکز توسعه‌دهنده نرم‌افزار قرار گرفت و این بار گفته شده است که تابستان امسال به عنوان بخشی از سیستم جامع Couchbase Server با نام SQL for Documents عرضه می‌شود. «باب ویدرهولد» مدیرعامل Couchbase در این خصوص گفت: «ابزار جدید به شما امکان می‌دهد به صورت گسترده‌تر با این سیستم سازگار شوید و از مزایای آن بهره‌مند گردید.» . ویدرهولد ابزار جدید را متفاوت با محصولات مشابه می‌داند و توضیح داده است که با آن امکان سازگاری با پایگاه داده متن‌باز MongoDB نیز فراهم می‌شود.




    این مسئله بسیار کاربردی به‌نظر می‌رسد که کدهای زبان برنامه‌نویسی SQL به یک استاندارد واحد تبدیل شود و پایگاه‌های داده مبتنی بر آن خدمات گسترده‌تری را برای در اختیار گرفتن داده و تحلیل آنها ارائه دهد. شرکت Couchbase می‌خواهد به یکی از ارکان اصلی زیرساخت‌های IT در سازمان‌ها تبدیل شود.
    در این راستا این شرکت نسخه ۴.۰ سیستم Couchbase Server را تابستان امسال روانه بازار می‌کند تا توسعه‌دهندگان نرم‌افزاری بتوانند امکانات بیشتری بر پایه سیستم SQL در اختیار بگیرند.

    * رایورز

  • #9
    مدير انجمن کاریابی Array itjobs آواتار ها
    تاریخ عضویت
    Saturday 24 February 2007
    نوشته ها
    6,116
    Thanks
    59
    Thanked 58 Times in 53 Posts

    پیش فرض


  • #10
    مدير انجمن کاریابی Array itjobs آواتار ها
    تاریخ عضویت
    Saturday 24 February 2007
    نوشته ها
    6,116
    Thanks
    59
    Thanked 58 Times in 53 Posts

  • صفحه 1 از 2 12 آخرینآخرین

    علاقه مندي ها (Bookmarks)

    علاقه مندي ها (Bookmarks)

    مجوز های ارسال و ویرایش

    • شما نمیتوانید موضوع جدیدی ارسال کنید
    • شما امکان ارسال پاسخ را ندارید
    • شما نمیتوانید فایل پیوست کنید.
    • شما نمیتوانید پست های خود را ویرایش کنید
    •