راه حل های مبتنی بر NoSQL ، عموما" به منظور پردازش داده در یک محیط توزیع شده طراحی شده اند . توزیع داده بین چندین گره در یک مرکز داده ، بهبود عملکرد را به صورت خطی و متناسب با بکارگیری تعداد بیشتری از گره ها  به دنبال خواهد داشت . ذخیره سازی ، بازیابی و  پردازش داده با رعایت اصل مهم مقیاس پذیری، نیازمند یک تجدید نظر کلی در رابطه با طراحی سیستم ها است .امروزه ، سازمان ها درگیر یک تغییر نگرش جدی در حوزه مدیریت حجم بالایی از داده نسبت به روش های سنتی مدیریت داده می باشند .الگوهای معماری داده NoSQL پاسخی شایسته به این تغییر نگرش می باشند . شکل 1 ، چهار گروه عمده بانک های اطلاعاتی NoSQL به همراه متداولترین محصول در هر گروه را نشان می دهد .


در بخش های گذشته با دو الگوی  معماری داده  Key-value  و Graph  آشنا شدیم . همانگونه که  اشاره گردید ، الگوهای فوق دارای ساختار ساده ای می باشند که برای حل مجموعه ای از مسایل کسب و کار مفید و قابل استفاده می باشند . در این بخش، بحث خود را در ارتباط با الگوهای معماری داده NoSQL ادامه داده و به سراغ یکی دیگر از این الگوها با نام  Column family خواهیم رفت و نشان خواهیم داد که چگونه می توان با ترکیب سطر و ستون یک جدول ، کلیدی جهت دستیابی به داده را ایجاد کرد . 

 مروری سریع بر الگوی معماری داده Column family
 سیستم های Column family یکی از الگوهای مهم  معماری داده NoSQL می باشند چراکه می توان از آنها برای مدیریت حجم بسیار بالایی از داده استفاده کرد .در سیستم های فوق از شناسه های سطر و ستون به عنوان کلیدهای همه منظوره  جهت جستجوی داده استفاده می گردد . از واژه data store در مقابل database استفاده می شود چراکه این نوع منابع ذخیره سازی داده ، فاقد ویژگی هایی مشابه با بانک های اطلاعاتی سنتی می باشند . مثلا ، این نوع منابع ذخیره سازی داده دارای ستون هایی با نوع های مشخص شده ، ایندکس های ثانویه ، trigger و زبان query نمی باشند . تقریبا تمامی سیستم های مبتنی بر الگوی معماری داده فوق  به نوعی در ارتباط با مقاله Bigtable  گوگل می باشند . به عنوان نمونه ، گرچه نحوه پیاده سازی   Hbase, Hypertable و Cassandra با یکدیگر متفاوت است ولی همگی آنها دارای اینترفیس هایی مشابه با Bigtable می باشند. 
معماری فوق ارتباط نزدیکی با بسیاری از سیستم های MapReduce دارد . MapReduce ، چارچوبی است که از آن برای انجام پردازش موازی بر روی مجموعه های بزرگ داده و در بین چندین کامپیوتر (گره) استفاده می گردد. در فریمورک MapReduce ، عملیات map دارای یک گره master است که وظیفه آن شکست یک عملیات به چندین قسمت و توزیع هر عملیات  به گره دیگر برای پردازش است . عملیات Reduce، فرآیندی است که در آن  گره master اقدام به جمع آوری نتایج از سایر گره ها و ترکیب آنها با یکدیگر با هدف پاسخ به مساله تعریف شده است. به دلیل اهمیت MapReduce در اینگونه الگوهای معماری داده در ادامه بطور مختصر اشاره ای به آن خواهیم داشت .

MapReduce چیست ؟
MapReduce ، یک الگوی برنامه نویسی است که امکان مقیاس پذیری گسترده را در بین صدها یا هزاران سرویس دهنده در یک کلاستر ( به عنوان نمونه کلاستر هدوپ ) فراهم می نماید . واژه فوق به دو فعالیت مجزا و جداگانه اشاره دارد . اولین فعالیت map نامیده می شود و وظیفه  آن دریافت مجموعه ای داده و تبدیل آن به مجموعه ای دیگر از داده است ( تبدیل عناصر منحصربفرد به زوج های کلید -مقدار ) . وظیفه reduce ،  دریافت خروجی یک map به عنوان ورودی و ترکیب گروهی از زوج های کلید - مقدار به گروه های کوچک تر است . همانگونه که از نام MapReduce مشخص است ، همواره فرآیند reduce بعد از فرآیند map انجام می شود . در ادامه  با بررسی یک مثال ساده ، سعی خواهیم کرد با مفاهیم کلیدی مدل برنامه نویسی  MapReduce بیشتر آشنا شویم.
مثال  : فرض کنید بخواهیم تعداد تکرار هر کلمه را در یک فایل ورودی محاسبه نماییم . برای انجام این کار مراحل زیر را می بایست دنبال کرد.

•  داده ورودی به تعدادی رکورد تقسیم می شود .
• تابع map، بر روی رکوردهای ایجاد شده در مرجله قبل پردازش لازم را انجام داده و برای هر کلمه موجود در رکورد، زوج کلید – مقدار را تولید می نماید .
•  تمامی زوج های کلید – مقدار که خروجی تابع map می باشند ، با یکدیگر ترکیب شده و بر اساس یک کلید گروه بندی و مرتب می گردند .
• نتایج میانی به تابع reduce ارسال می شوند تا خروجی نهایی را تولید نماید .

مراحل کلی برنامه MapReduce فوق در شکل2 نشان داده شده است .


 اصول اولیه الگوی معماری داده Column family  
به عنوان اولین نمونه از نحوه استفاده سطرها و ستون ها به عنوان یک کلید ، می توان به صفحات گسترده  ( spreadsheet ) اشاره کرد.گرچه اکثر ما صفحات گسترده را به عنوان یک فناوری NoSQL در نظر نمی گیریم ، ولی یک روش ایده آل برای تصور این موضوع هستند که چگونه می توان کلیدها را با بیش از یک مقدار ایجاد کرد . شکل  3 ، یک صفحه گسترده را  با یک سلول در سطر 3 و ستون 2 ( ستون B ) که حاوی کلمه 'فابک' است ، نشان می دهد. سلول دارای آدرس 3B است و می توان آن را به عنوان کلید جستجو در یک سیستم ماتریس Sparse در نظر گرفت .


در یک صفحه گسترده می توان از تلفیق شناسه های سطر و ستون  جهت بازیابی مقدار ذخیره شده در یک سلول بخصوص استفاده کرد . مثلا ستون سوم در سطر دوم توسط کلید C2 شناسایی می شود. در مقایسه با  key-value store که دارای یک کلید تک برای شناسایی مقدار است ، یک صفحه گسترده دارای شناسه های سطر و ستون است که با ترکیب آنها کلید دستیابی به یک سلول ایجاد می گردد . همانند key-value store می توان آیتم های مختلفی را در یک سلول قرار داد.یک سلول می تواند شامل داده ، فرمول و یا حتی یک تصویر باشد. وضعیت آدرس دهی در یک صفحه گسترده جهت دستیابی به یک سلول بخصوص در شکل 4 نشان داده شده است.


این مفهوم دقیقا مشابه سیستم های column family است . هر آیتم داده را می توان با آگاهی از شناسه های سطر و ستون آن پیدا کرد و همانند یک صفحه گسترده می توان داده را در هر سلول درج کرد . برخلاف یک سیستم مدیریت بانک اطلاعاتی رابطه ای (RDBMS ) مجبور نیستیم که داده را برای تمامی ستون های یک سطر درج کنیم .

 آشنایی با کلیدها   
تا این جای کار ما با مفهوم کلیدهای ترکیبی جهت دستیابی به یک داده بخصوص آشنا شدیم . فرض کنید به صفحه گسترده دو فیلد column family و timestamp را اضافه کنیم . ساختارکلید در column family stores مشابه یک صفحه گسترده است با این تفاوت که دارای دو خصلت اضافه دیگر است .علاوه بر نام ستون ، از یک Column family جهت گروه بندی اسامی ستون مشابه استفاده شده است . اضافه کردن یک timestamp در کلید ، این امکان را فراهم می نماید تا بتوان چندین نسخه از یک مقدار را در  طول زمان در هر یک از سلول ها ذخیره کرد. . کلید نشان داده شده در شکل 5 ، نمونه ای از column stores است .


برخلاف ، صفحه گسترده معمولی که ممکن است دارای 100 سطر و ستون باشد ، column family store برای حجم بسیار بالایی از داده طراحی شده است . سیستم هایی با میلیاردها سطر و صدها یا هزاران ستون!
به عنوان نمونه یک برنامه GIS ( برگرفته شده از Geographic Information System ) نظیر Google Earth ممکن است از یک شناسنه سطر ( Row ID ) به عنوان طول جغرافیایی یک نقشه و از نام ستون به عنوان عرض جغرافیایی استفاده نماید . مثلا در یک نقشه برای هر مایل مربع ، می توان از 15000 شناسه سطر و 15000 شناسه ستون استفاده کرد . در صورت پیاده سازی یک سیستم GIS به کمک یک صفحه گسترده ، مشاهده می شود که تعداد اندکی از سلول ها حاوی داده می باشند .چیزی که این پیاده سازی را غیرمعمول می سازد این است که صرفا درصد اندکی از سلول ها حاوی اطلاعات می باشند . این نوع پیاده سازی مشابه ماتریس های sparse  است که صرفا تعداد محدودی از ستون های آن دارای مقدار می باشند. متاسفانه ، بانک های اطلاعاتی رابطه ای برای ذخیره داده sparse مناسب نمی باشند ولی column stores برای پاسخ به اینگونه اهداف طراحی شده اند. در یک بانک اطلاعاتی رابطه ای ، می توان از یک query ساده برای یافتن تمامی ستون ها در هر جدولی استفاده کرد . در صورت اجرای یک query بر روی sparse matrix ، برای یافتن هر عنصر در بانک اطلاعاتی ، می بایست تمامی اسامی ستون ها را جستجو کرد . جستجوی تمامی ستون ها برای یافتن یک داده بخصوص و یا لیست تمامی داده بر اساس یک شرط خاص می تواند نتایج اغواکننده ای را نیز به دنبال داشته باشد.برای حل این نوع مسایل می توان از مفهوم column family استفاده کرد . به عنوان نمونه می توان ستون ها را به منظور تشریح یک وب سایت ، یک شخص ، یک مکان جغرافیایی و یا محصولات فروش رفته گروه بندی کرد. برای مشاهده این ستون ها با یکدیگر ، آنها را در column family مشابه گروه بندی می کنیم تا امکان بازیابی سریع آنها فراهم شود .
تمامی column family stores از یک column family به عنوان بخشی از کلید خود استفاده نمی کنند. در صورت استفاده ، می بایست آن را در محاسبات خود در زمان ذخیره یک کیلد در نظر گرفت . چراکه column family بخشی از کلید است و بازیابی داده بدون آن میسر نمی باشد.

مزایا و محدودیت های سیستم های column family 
رویکرد column family با استفاده از یک شناسه سطر و نام ستون به عنوان یک کلید جستجو ، روشی انعطاف پذیر برای ذخیره داده است که دارای مزایای متعددی نظیر مقیاس پذیری ، در دسترس بودن و عدم از دست دادن زمان در هنگام اضافه کردن داده به سیستم است .با توجه به این که سیستم های Column family متکی به Join نمی باشند ، می توان به خوبی از آنها در سیستم های توزیع شده استفاده کرد . با این که می توان کار پیاده سازی را بر روی یک لپ تاپ شروع کرد ولی در نهایت کار استقرار را می توان بگونه ای پیکربندی کرد که داده را در سه ناحیه جغرافیایی مختلف ذخیره کرد( افزایش قابلیت در دسترس پذیری سیستم ) . سیستم های column family دارای امکانات اتوماتیکی برای برخورد با مشکلات و تشخیص گره های دارای مشکل و الگوریتم هایی برای شناسایی خرابی داده می باشند. Column family بگونه ای پیاده سازی شده است تا بتواند با سیستم فایل های توزیع شده (نظیر  Hadoop ) و MapReduce کار کند. لازم است قبل از پیاده سازی به موارد فوق و نکات زیر دقت شود .

• مقیاس پذیری بالا : سیستم های column family به منظور کار با بیش از یک پردازنده طراحی شده اند و همین موضوع قابلیت مقیاس پذیری بالای آنها را نشان می دهد. این بدان معنی است که شما می توانید به هر میزان داده که لازم دارید به سیستم خود اضافه نمایید. در چنین مواردی می توان گره های جدید را به کلاستر محاسباتی اضافه کرد. به موازات رشد داده ، می توان تعداد پردازنده ها را نیز اضافه کرد. دلیل اصلی مقیاس پذیری این روش ، مدل ساده یی است که در آن از شناسه های سطر و اسامی ستون ها به منظور شناسایی یک سلول استفاده می گردد . در واقع با ایجاد و نگهداری یک اینترفیس ساده ، سیستم back end می تواند درخواست ها را بین تعدادی از گره های پردازش بدون انجام عملیات join توزیع نماید و از ترافیک غیرضروری پیشگری و کارآیی سیستم را افزایش دهد.
• در دسترس پذیری بالا : با ایجاد سیستمی که قادر به رشد در طول شبکه های توزیع شده باشد، می توان داده را بر روی چندین گره یک شبکه تکرار کرد . با توجه به این که سیستم های column family از ارتباطات موثر استفاده می نمایند ، هزینه تکرار پائین خواهد بود . علاوه براین ، فقدان عملیات Join اجازه می دهد که بتوان هر بخشی از ماتریس column family را بر روی کامپیوترهای راه دور ذخیره کرد . این بدان معنی است که اگر سرویس دهنده ای که بخشی از ماتریس sparse را ذخیره کرده باشد دچار مشکل گردد ، سایر کامپیوترها آماده ارایه سرویس داده می باشند .
•  تسهیل در اضافه کردن داده : یکی از ویژگی های کلیدی Column family همانند key-value stores و Graph stores عدم ضرورت طراحی کامل مدل داده ، قبل از درج داده است .قبل از هر چیز می بایست گروه بندی column family مشخص گردد ولی شناسه های سطرها و اسامی ستون ها را می توان در هر زمانی ایجاد کرد.

علی رغم تمامی مزایای اشاره شده در رابطه با سیستم های Column family، این گونه سیستم ها جهت استفاده  بر روی کلاسترهای توزیع شده به کار گرفته می شوند  و مناسب بانک های اطلاعاتی کوچک نیستند . معمولا به حداقل پنج پردازنده جهت ایجاد یک کلاستر column family نیاز خواهید داشت.همچنین، سیستم های Column family از SQL query برای دستیابی بلادرنگ به داده استفاده نمی کنند . این گونه سیستم ها دارای یک زبان query در یک سطح بالاتر می باشند .  از سیستم های Column family اغلب جهت تولید کارهای دسته ای MapReduce استفاده می شود . جهت دستیابی سریع به داده ، می توان از یک رابط برنامه نویسی سفارشی شده نوشته شده با یک زبان رویه ای نظیرجاوا یا Python استفاده کرد .

 مثال 1 : ذخیره اطلاعات تحلیلی توسط گوگل در BigTable  
 در مقاله Bigtable شرکت گوگل ، به این موضوع اشاره شده است که چگونه می توان از BigTable برای ذخیره اطلاعات یک وب سایت در Google Analytics استفاده کرد . سرویس Google Analytics این امکان را فراهم می نماید که بتوان ملاقات کنندگان یک وب سایت را پیگیری کرد . هر زمان که کاربری بر روی یک صفحه وب کلیک می نماید ،اطلاعات آن در یک row-column ذخیره می گردد که دارای یک URL و یک timestamp به عنوان row ID است . همانگونه که حدس زده اید ، مشاهده جزئیات لاگ تمامی مشاهدات کاربر بر روی وب سایت می تواند یک فرآیند طولانی باشد. Google Analytics این کار را از طریق خلاصه کردن داده در فواصل زمانی خاص (نظیر یک مرتبه در روز) انجام می دهد. Google Analytics یک نمونه  خوب از یک بانک اطلاعاتی بزرگ است که دارای یک رشد خطی است (همزمان با افزایش تعداد کاربران). به موازات این که یک رویداد جدید محقق می شود ، داده جدید بلافاصله به جدول اضافه می شود ، ولو این که یک گزارش در حال اجراء باشد .
داده در Google Analytics نظیر سایر برنامه هایی از نوع logging ، معمولا یک مرتبه نوشته می شوند و هرگز بهنگام نمی شوند . این بدان معنی است که پس از استخراج و خلاصه کردن ، داده اولیه فشرده شده و در یک مکان ذخیره سازی میانی قرار می گیرد تا بایگانی شود . در مواردی که از HBase به عنوان محل ذخیره سازی BigTable استفاده می شود ، لازم است نتایج در HDFS ( برگرفته شده از Hadoop distributed filesystem ) ذخیره گردند و از یک ابزار گزارش گیری نظیر Hadoop Hive برای تولید خلاصه گزارشات استفاده شود . Hadoop Hive دارای یک زبان query است که در بسیاری موارد شبیه SQL کار می کند .

مثال 2 : ذخیره اطلاعات جعرافیایی گوگل مپ در BigTable
 یک نمونه دیگر استفاده از BigTable برای ذخیره حجم بالایی از اطلاعات ، اطلاعات GIS است . سیستم های GIS نظیر Google map اطلاعات نقاط جغرافیایی زمین ، ماه و سایر سیارات را با شناسایی هر مکان با استفاده از مختصات طول و عرض جغرافیایی انجام می دهند . سیستم به کاربران اجازه می دهد بر روی زمین حرکت کرده و بر روی آن زوم نمایند . برای تسهیل کار با سیستم از اینترفیس های گرافیکی سه بعدی استفاده شده است . سیستم های GIS ، آیتم ها را یک مرتبه ذخیره می کنند و امکان دستیابی و  مشاهده داده را به کمک مسیرهای مختلف فراهم می نمایند .  

خلاصه
 دراین بخش با الگوی معماری داده Column family store آشنا شدیم. در معماری فوق ، کلید دستیابی به اطلاعات از چندین آیتم تشکیل می گردد ( به عنوان نمونه شناسه یک سطر ، column family و نام ستون ) و می توان بر روی هر یک از آیتم های  اشاره شده query زد. این نوع بانک های اطلاعاتی قابلیت رشد بسیار خوبی را دارند و قادر به نگهداری چندین نسخه از اطلاعات می باشند. شیوه طراحی سطرها و ستون ها در این مدل بسیار حائز اهمیت است .
Cassandra, HBase, Hypertable, Apache Accumulo  و Bigtable نمونه هایی از بانک های NoSQL می باشند که از الگوی معماری داده Column family  استفاده می کنند . در بخش چهارم به بررسی الگوی معماری داده Document store خواهیم پرداخت .