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

[دانه کولانه]

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

اگر گمان مي‌کنيد که ديتابيس‌هاي SQL همه از نوع رابطه‌اي هستند، بايد بگوييم که اشتباه مي‌انديشيد. NoSQL يك پايگاه داده‌اي غيررابطه‌اي و توزيع شده است که نيازي به جدول ندارد و مي‌تواند به‌سادگي عمليات Replication را انجام دهد. ديتابيس‌هاي NoSQL آنجايي جذاب مي‌شوند که ضعف‌هاي RDBMS به‌چشم مي‌خورد: اين پايگاه‌هاي داده براي يک کاربر و يک دستگاه و يک عمليات در لحظه ساخته شده‌اند. RDBMSها جوابگوي نظام محاسباتي فعلي دنيا نيستند که در لحظه هزارها و ميليون‌ها کاربر مي‌خواهند به پايگاه داده‌اي پر از تصوير و فيلم و داده ديجيتال دسترسي پيدا کنند.

مقدمه:
اگر گمان مي‌کنيد که ديتابيس‌هاي 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 راهكارهايي براي ايجاد سيستم‌هاي توزيع‌شده، بي‌درنگ و با دسترسي بالا در اختيار مي‌گذارد. با توجه به رشد سرويس‌هاي شبكه‌اي، بهره بردن از اين پلت‌فرم و اين زبان، يك امتياز براي كوچ به‌حساب مي‌آيد.

رابط كاربري تحت وب فوتون

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

http://localhost:5984/_utils

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

http://couchdb.apache.org/
http://books.couchdb.org

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

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

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


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

منابع:

http://www.barnamenevis.org/forum/showthread.php?t=224790
پايگاه‌هاي داده مبتني بر سند، از جديدترين سيستم‌هاي مديريت پايگاه‌هاي داده به‌ شمار مي‌آيند. (مثل لوسنت از همین آپاچی)
اين نوع از پايگاه داده، بر خلاف ديتابيس‌هاي رابطه‌اي، داده‌ها را در جداول ذخيره نمي‌كنند و در نتيجه، هيچ اندازه ثابتي براي داده‌ها در نظر نمي‌گيرند. اما، از طرف ديگر، هر ركورد به‌عنوان سندي با ويژگي‌هاي خاص ذخيره مي‌شود. در اين سند، هر تعداد فيلد با هر طولي مي‌تواند ذخيره شود

http://jamejamonline.ir/papertext.aspx?newsnum=100883162456
پايگاه‌هاي داده رابطه‌اي در نرم‌افزارهايي كه داده‌هاي سنگيني دارند، بازدهي كمي دارند. مثلا براي انديس‌گذاري تعداد زيادي از سندها يا ارائه صفحه‌هاي اينترنت در وب‌سايت‌هايي كه جريان داده بالايي دارند، پايگاه‌هاي داده رابطه‌اي پاسخگو نخواهند بود و ...




بنده از

http://www.pcpedia.ir/ViewArticle.aspx?ID=289
برداشت کردم.

[دانه کولانه]

دیتابیس Nosql

[PDF] Perspectives on NoSQL

[PDF] NoSQL Tutorial

اموزش nosql

Introduction to NOSQL and cassandra

https://docs.google.com/present/view...kc_145c5gmf2gz

[دانه کولانه]

NoSQL Tutorial آموزش نو اس کیو ال

A comprehensive look at the NoSQL database.

Some months ago I had a discussion with NoSQL creator, Carlo Strozzi, regarding the databases.

I should admit, I am an SQL fan! It's hot having the same language, no matter which platform or database
engine is used. He underlined the fact that most SQL engines lack of flexibility and waste system resources
(memory and disk space) because of their multi-platform environment (such as Oracle, DB2, Informix, etc.).

He suggested I have a look at the white paper that inspired him: ``The UNIX Shell As a Fourth Generation
Language'' by Evan Schaffer (evan@rsw.com) and Mike Wolf (wolf@hyperion.com).

Quoting from the above paper:

... almost all [database systems] are software prisons that you must get into and leave the power
of UNIX behind. [...] The resulting database systems are large, complex programs which
degrade total system performance, especially when they are run in a multi-user environment.
[...] UNIX provides hundreds of programs that can be piped together to easily perform almost
any function imaginable. Nothing comes close to providing the functions that come standard
with UNIX.

The UNIX file structure is the fastest and most readily-available database engine ever built: directories may be
viewed as catalogs and tables as plain ASCII files. Commands are common UNIX utilities, such as grep, sed
and awk. Nothing should be reinvented.

NoSQL was born with these ideas in mind: getting the most from the UNIX system, using some commands
that glue together various standard tools. Although NoSQL is a good database system, this is not a panacea for
all you problems. If you have to deal with a 10 gigabytes table that must be updated each second from various
clients, NoSQL doesn't work for you since it lacks of performance on very big tables, and on frequent updates
you must be in real time. For this case, I suggest you use a stronger solution based on Oracle, DB2 or such
packages on a Linux cluster, AS/400 or mainframes.

However, if you have a web site containing much information and more reading occurs than writing, you will
be surprised how fast is it. NoSQL (pronounced noseequel, as the author suggests) derives most of its code
from the RDB database developed at RAND Organization, but more commands have been built in order to
accomplish more tasks.

Installing NoSQL

ادامه را در فایل پی دی اف زیر دانلود کنید
http://www.gpaterno.com/publications...L_Tutorial.pdf

[دانه کولانه]

NoSQL Tutorial آموزش

Installing NoSQLThe latest NoSQL source code can be found at ftp://ftp.linux.it/pub/database/NoSQL,

از ادرس بالا Nosql رو دانلود کنین
از ادرس
http://www.linuxjournal.com/article/3294?page=0,0
متعلق به

هم اموزش رو بخونین .