COUCHBASE چیست؟

Couchbase server یک دیتابیس opensource، توزیع شده و بر پایه Json است. مقادیری که به صورت key-value ذخیره شده اند با استفاده از cache مدیریت می شوند که این امر باعث می شود مدت زمان انجام عملیات بر روی داده ها زیر میلی ثانیه انجام شود. علاوه بر این به صورت داخلی دارای یک indexer می باشد که از آن برای پیاده سازی کوئری های موثر استفاده می شود.

این دیتابیس یک query engine بسیار قوی برای اجرای کوئری های مشابه SQL را هم دارد. این دیتابیس برای مقاصد mobile و IoT هم سولوشن دارد.

این دیتابیس مدیریت اطلاعات را برای اپلیکیشن ها تحت وب در مقیاس بزرگ، IoT و mobile را به صورت low-latency انجام می دهد.

این دیتابیس نیازمندی های زیر را تحت پوشش قرار می دهد:

  • Unified Programming Interface
  • Query
  • Search
  • Mobile and IoT
  • Analytics
  • Core database engine
  • Scale-out architecture
  • Memory-first architecture
  • Big data and SQL integrations
  • Full-stack security
  • Container and Cloud deployments
  • High Availability

Unified Programming Interface:

API های مورد استفاده در این دیتابیس بسیار ساده هستند و علاوه بر آن می توان در چندین زبان برنامه نویسی از آن استفاده کرد.

پیاده سازی و مدیریت آن ساده می باشد و امکانات زیادی از جمله replication و automatic sharding را به صورت built-in دارد.

به صورت کلاستر قابل پیاده سازی می باشد و این کلاستر از طریق یک console مدیریتی قابل مدیریت می باشد. علاوه بر این قابلیت cross-datacenter replication هم به ساده گی در این دیتابیس قابل پیاده سازی می باشد. به طور کلی مدیریت کلاستر این دیتابیس بسیار ساده می باشد.

Query:

از مسیر های دسترسی به اطلاعات (data access pattern) متنوعی پشتیبانی می کند که کار developer ها را آسان کرده. این مشخصه باعث می شود که بتوان از این دیتابیس برای موارد متنوعی استفاده کرد.

این دیتابیس از N1QL پشتیبانی می کند. N1QL بسیار قوی می باشد و از SQL هم پشتیبانی می کند.

بر خلاف دیگر NoSQL database ها، این دیتابیس از Join operation و data model های زیادی را پشتیبانی می کند

Full-text search:

با استفاده از این قابلیت که به صورت built-in در این دیتابیس است، به developer های این امکان را می هد تا به اپلیکیشن، هوشمندی اضافه کنند.

Mobile and Internet of Things:

Analytics:

این دیتابیس پردازش کوئری های موازی بسیار قوی را برای شما فراهم می کند. با استفاده از این امکان می توان کوئری های پیچیده و طولانی، join های پیچیده را انجام داد.

Core Database Engine:

این مشخصه از این دیتابیس امکانات بنیادی را برای مدیریت داکیومنت ها و indexing را فراهم می کند. علاوه بر این، اقدامات مربوط به caching, data persistence و ارتباط بین nodeها را هم انجام می دهد.

اطلاعات داخل این دیتابیس به صورت Json است که مزیت های خاص خودش را دارد.(self-describing, rich structure). بر خلاف RDBMS های قدیمی، مفهوم schema در این دیتابیس به صورت تماما منطقی (logical) در داخل کد اپلیکیشن تعریف می شود. از آنجاییکه که دیگر schema با مفهوم قدیمی برای نگهداری وجود ندارد، توسعه دهندگان میتوانند در هر زمانی object و properties های مختلف را در کد به صورت json جدید اضافه کنند. این امر موجب افزایش سرعت در توسعه اپلیکیشن شود.

Scale-out Architecture:

برای سرویس های بسیار حساس باید از دیتابیس استفاده کرد که توانایی این را داشته باشد که همیشه up&running باشد و دائما در حال سرویس دهی باشد. این دیتابیس به صورت built in به صورت توزیع شده کار میکند و اطلاعات را ذخیره می کند.

Couchbase طوری طراحی شده است که بتوان به راحتی آن را Scale کرد.

Replication و sharding دو مشخصه اصلی و بنیادی این دیتابیس است. به صورت اتوماتیک دیتا را در سطح کلاستر توزیع می کند. بنابراین به راحتی می توان دیتابیس را به صورت horizontally رشد داد و بار کاری توسعه دهندگان و مدیران سیستم را افزایش نداد.

این دیتابیس با استفاده از nonblocking and asynchrony I/O به صورت موثر و بهینه از سخت افزار سرور استفاده می کند. این مشخصه باعث می شود که بهره وری Storage I/O  و تعداد کاربر استفاده کننده همزمان، افزایش یابد.

معماری این دیتابیس به گونه ای است که load بر روی تمامی نود ها تقسیم می شود به نحوی که از سحت افزار موجود به صورت کامل استفاده شود و در کلاستر bottlenecks خاصی ایجاد نشود.

Memory-first Architecture:

این دیتابیس به صورت حافظه محور یا memory-centric می باشد به این صورت که یک سری اطلاعات از جمله داکیومنت های زیاد استفاده شده، metadata و index ها به دلیل سرعت بیشتر در خواندن و نوشتن و همچنین تاخیر کمتر، در RAM نگهداری می شود.

این قابلیت با استفاده از integral object managed cache که یک hash table  بر پایه تکنولوژی caching توزیع شده Memcached است به وجود می آید.

Big Data and SQL Integrations:

Full-stack Security:

Container and Cloud Deployments:

High Availability:

این دیتابیس بر مبنای اطمینان پذیری بالا، دسترس پذیری بالا و مدیریت ساده ساخته شده است. یکی از مشخصه های این دیتابیس این است که شما به صورت آنلاین می توانید تغییرات و عملیات مختلف را روی آن انجام دهید. برای انجام برخی از task های نگهداری مانند به روز رسانی، ساخت index، فشرده سازی، تغییرات سخت افزاری و ... احتیاجی به آفلاین کردن سرور نیست. حتی  اضافه کردن یا حذف کردن یک نود به کلاستر هم می تواند آنلاین و بدون وقفه در کار توسعه دهندگان انجام شود.

این دیتابیس به صورت built in مکانیزم replication  و failover را دارد. این کار را با کپی کردن اطلاعات در نود های مختلف انجام می دهد. این عملیات به صورت کاملا اتوماتیک انجام می شود.

همچنین می توان با استفاده از Cross Data Center Replication (XDCR) یک کپی تمام کلاستر در نقطه جغرافیایی دیگر داشته باشیم. XDCR به شما این امکان را می دهد که دسترس پذیری بالا، disaster recovery و load balancing جغرافیایی داشته باشید.

Couchbase سرور شامل چندین سرویس می باشد که هر کدام می تواند به صورت مستقل نصب و راه اندازی شوند. بنابراین امکان scale شدن در چند بعد فراهم می باشد. تصویر زیر برای یک محیط development می باشد.

حالا اگر بخواهیم این کلاستر را برای محیط production به صورت tune شده نصب و راه اندازی کنیم، معماری شبیه به این را در نظر می گیریم  این معماری به صورت multidimensional scaling می باشد.

در این طراحی اینطور پیش بینی شده است که دو سرویس data وindex نسبت به دو سرویس query و search بار کاری بیشتری انجام می دهند

تمامی سرویس های این دیتابیس به شرح زیر می باشد:

Data: برای ذخیره و بازیابی اطلاعات از این سرویس استفاده می شود. مشخصا با key شناخته می شود.

Query: با استفاده از زبان N1QL می توان روی این دیتابیس query زد. این سرویس با دو سرویس Data و Index در ارتباط می باشد.

Index: وظیفه ساخت index را دارد. سرویس query از این index ها استفاده می کند.

Search: وظیفه ساخت یک سری Index خاص برای full text search را به عهده دارد. از جستجو language aware پشتیبانی می کند. مثلا کاربر کلمه beauties را جستجو می کند و در نتیجه  beauty و  beautiful را مشاهده می کند.

Analytics: از عملیات های join, set, aggregation و grouping پشتیبانی می کند که منابع زیادی هم برای اجرا مصرف می کند.

Eventing: برای پشتیبانی از تغییرات real-time داده ها استفاده می شود.

Backup: برای گرفتن Backup به صورت full و incremental استفاده می شود. همچنین می توان از bucket خاص هم backup گرفت. همه این موارد هم قابل scheduling می باشد.

برخی اصطلاحات در Couchbase:

Date: در این دیتابیس اطلاعات در قالب item ذخیره می شود. هر item شامل key و value است که از طریق key قابل ارجاع می باشد.

Buckets, Memory, and Storage: هر item در bucket نگهداری می شود و هر bucket در memory و برخی دیگر هم در memory و هم در storage ذخیره می شود. نکته مهم این است که اول حتما باید bucket باشد که item داخل آن ذخیره شود.

Services and Indexes: سرویس ها برای انواع مختلف بازیابی اطلاعات پیاده سازی می شوند. برای مثال سرویس Data این امکان را به شما می دهد که هر item را با استفاده از key بازیابی کنید در حالی که سرویس query این امکان را با N1QL به شما می دهد.

Clusters and Availability: یک سرور که روی آن Couchbase نصب شده است یک کلاستر تک نود به حساب می آید. می توان با اضافه کردن نود به این کلاستر availability آن را افزایش داد. اطلاعات در تمام نود های کلاستر ذخیره می شود همچنین اگر شما یک کلاستر در یک دیتاسنتر دیگر داشته باشید میتوانید انتخاب کنید که اطلاعات در کدام کلاستر در کدام دیتاسنتر replicate شود. امکان حذف و اضافه کردن نود بدون از دست دادن اطلاعات به سادگی میسر می باشد.

شرح Data Service:

بنیادی ترین سرویس این دیتابیس Data می باشد که دسترسی به اطلاعات در Ram و Disk را فراهم می کند. این سرویس حداقل باید روی یک نود در کلاستر اجرا شود.

معماری این سرویس در ادامه آورده شده است:

اجزای اساسی این سرویس به شرح زیر می باشد:

Dispatcher: هر درخواست برای اطلاعات را کنترل و مدیریت می کند. همچنین مسئول انتقال اطلاعات به سایر نود های کلاستر می باشد.

KV Engine: وظیفه این جز از سرویس Data فراهم آوردن برخی امکانات برای Bucket ها از جمله Cache, checkpoint, Item pager, Flusher, Expiry Pager.

Scheduler: شامل مخزنی از thread ها می باشد با هدف کنترل I/O می باشد. این thread ها به چهار دسته تقسیم می شوند:

            Non io: task هایی که احتیاج به دسترسی به دیسک را ندارند. مانند checkpoint removal, hash table resizing

                Aux io: وظیفه scan, fetch و اجرای مجدد task ها را به عهده دارد.

            Reader io: thread های هستند که اطلاعات را از disk می خوانند.

            Writer io: thread های هستند که اطلاعات را در disk می نویسند.

شرح Query Service:

زبان کوئری که این سرویس از آن استفاده می کند N1QL می باشد و ساختار آن در تصویر زیر آورده شده است:

Listeners: درخواست های مربوط به کوئری ها روی پورت 8093 و 18093 دریافت می شود.

Query Processor: برای هر query یک parser تعیین می کند. با این کار می تواند valid statement ها را شناسایی کند. با استفاده از optimizer راه های اجرای کوئری را ارزیابی می کند تا بتواند کوئری را با کمترین تاخیر اجرا کند. در نهایت Execution Engine عملیات دریافتی را تا جایی که ممکن باشد به صورت موازی اجرا می کند.

Data Stores: دو نوع data store داریم. Couchbase serverبرای دسترسی به اطلاعات ذخیره شده در index ها و Data در سرور است. نوع دوم هم برای ذخیره local ی است.

شرح سرویس Index:

اجزای لازم و ضروری این سرویس نه تنها در نود هایی است که سرویس index در آن نصب شده بلکه در نود هایی که سرویس Data در آن نصب شده است هم هست.

Data service: از پروتکل DCP برای stream کردن داده به projector و router استفاده می کند که در حقیقت به عنوان بخشی از سرویس index در سرویس data اجرا می شود.

Projector and Router: وظیفه این جز در حقیقت فراهم کردن دیتا برای سرویس index طبق تعاریفی که Supervisor در سرویس index دارد ، می باشد. این تعاریف در همان ابتدای ساخت index ها ایجاد می شود و به Projector and Router ارسال می شود.

Projector and Router با سرویس data در ارتباط است و طبق تعاریف که در مرحله قبل ایجاد شده، اطلاعات را Extract می کند و آنها را به supervisor ارسال می کند.

دائما هم این stream را کنترل می کند که اگر تغییر مشاهده کند آن را به Supervisor اطلاع دهد تا supervisor تغییرات در تعارف اعمال کند.

Supervisor: علاوه بر ایجاد تعاریف وظیفه ساخت و ذخیره index ها بر عهده دارد همچنین تغییرات ارسالی از سمت Projector and Router بر روی index ها کنترل می کند.

Query Service: درخواست ها به supervisor ارسال می شود و پاسخ دریافت می کند.

ذخیره سازی Index:

به صورت پیش فرض index در همان نودی که ایجاد شده ذخیره هم می شود. هر index در یک keyspace ایجاد می شود ولی چند index هم میتواند در یک keyspace باشد.

سرویس Index میتواند طوری پیکربندی شود که از standard storage یا memory-optimized storage استفاده کند.

            standard storage:

            supervisor تمامی تغییرات بر روی index ها را روی disk ذخیره می کند.

            Memory-Optimized:

            اطلاعات روی Memory ذخیره می شود و تنها یک snapshot در disk ذخیره می شود. در نسخه Enterprise هم فقط موجود می باشد.

شرح سرویس Search:

این سرویس قابلیت بسیار قوی برای کوئری های natural-language ارائه می دهد که شامل موارد زیر می شود:

جستجوی Language-aware: برای مثال کاربر کلمه beauties را جستجو می کند و در نتایجی شبیه به beauty and beautiful را مشاهده میکند.

Scoring of results, according to relevancy: به کاربر این امکان را میدهد که تنها نتایجی را مشاهده کند که امتیاز بیشتری دارد. این امتیاز دهی به نتایج حاصل search را بسیار کاهش می دهد.

Fast indexes: امکان جستجو از گستره وسیعی از text را فراهم می کند.

سرویس search برای کار خودش تعدادی index درست می کند که کاملا متفاوت از index های سرویس index است.

سرویس search به سرویس Data وابستگی دارد.

زمانی که یک search index به وسیله سرویس search ایجاد شد اطلاعات یک بخشی از bucket ها را نگهداری میکند. مثلا اگر ما 120 bucket داشته باشیم ، 6 search index در نظر گرفته می شود که هر کدام از search index ها اطلاعات 20 bucket را نگهداری می کند.

هر نود از کلاستر که روی آن سرویس search باشد به تنهایی قابل سرچ می باشد. زمانی که سرویس search از یک نود برای کار انتخاب می شود، نقش coordinator میگیرد و مسئول انجام عملیات search روی تمام نود ها و جمع آوری نتایج می شود

اپلیکیشن درخواست search خودش را به یک نود ارسال می کند در اینجا نود 1 انتخاب می شود. آن نود به coordinator تبدیل می شود و در خواست را بین search index ها پخش می کند. در تصویر فوق منظور نود 2 و نود 3 هستند.

زمانی که اطلاعات جمع آوری شده به نود 1 ارسال شد آن نود فیلتر های لازم را اعمال کرد نتیجه نهایی به کاربر ارسال خواهد شد.

شرح سرویس :Analytics

سرویس Analytics به شما امکان تحلیل اطلاعات JSON های داخل دیتابیس را به صورت real time بدون احتیاج به Extract, transform یا ETL به یک سرور دیگر را می دهد.

این سرویس از معماری massively parallel processing (MPP) برای اجرای query های سنگین و پیچیده استفاده می کند.

این سرویس به شما اجازه توسعه سریع و آسان اپلیکیشن های insight-driven را می دهد.

این سرویس از اطلاعاتی که قرار است مورد تحلیل قرار بگیرند، یک shadow copy تهیه می کند و آن را به سرویس data متصل می کند بدین ترتیب  با استفاده از پروتکل Database Change Protocol (DCP) هر تغییر در اطلاعات operational خیلی سریع در این shadow copy اعمال می شود.

با توجه به حجم اطلاعات و جنس کاری که این سرویس انجام می دهد، این سرویس باید به صورت مستقل روی یک node راه اندازی شود.

شرح سرویس Backup:

با استفاده از این سرویس می توان به صورت full و incremental از تمام اطلاعات یا bucket خاص backup در زمانبندی خاص تهیه کرد. همچنین با استفاده از این سرویس شما می توانید backup های قبلی را با هم merge کنید.

معماری:

این سرویس از معماری leader-follower استفاده می کند. یعنی یک node به عنوان leader انتخاب می شود تا انتقال task های backup ، اضافه و حذف node های backup، پاکسازی orphan task و اطمینان از این که محل ذخیره سازی backup برای همه node های سرویس در دسترس می باشد را بررسی کند.

اگر leader node به هر دلیل دچار اختلال شود سرویس stop می شود تا زمانی که عملیات rebalancing انجام شود و leader جدید انتخاب شود. پس از انتخاب leader دوباره فرایند از سر گرفته می شود.

Administrator می تواند این سرویس را برای اجرا schedule کند و plan مشخص کند مانند:

مشخص کردن این که چه سرویسی احتیاج به تهیه backup دارد، کدام backup ی باید اجرا شود، چه نوع backup ی باید اجرا شود.

برای ذخیره backup ها احتیاج به مشخص کردن مکانی با نام repository است. نام این repository باید در تمام کلاستر منحصر به فرد باشد. اگر به repository احتیاجی نبود می شود آن را به حالت Archive در آورد که دیگر backup ی دریافت نکند و به صورت یک فایل locally ذخیره شود.

Clusters and Availability:

یک کلاستر دیتابیس Couchbase شامل یک یا بیشتر از یک node می باشد که تمام اطلاعات و سرویس ها بین آنها به صورت Shared در دسترس می باشد.

زمانی که Couchbase را نصب می کنید به شما اجازه می دهد که سرور مورد نظر تشکیل یک کلاستر بدهد یا join به کلاستر موجود بشود. زمانی که یک کلاستر چند node داشته باشد cluster manager روی همه آنها نصب می شود که ارتباطات بین node ها مدیریت کند و از سلامت همه آنها مطمئن شود. Cluster manager اطلاعات کلاستر را به شما در web console نمایش می دهد.

اطلاعات به صورت اتوماتیک در تمام کلاستر پخش می شود و Couchbase آن را مدیریت می کند. هر bucket تعریف شده توسط سرویس data در قالب 1024 vbucket ذخیره می شود. تمام این vbucket ها در سرویس data که در هر node است ذخیره می شود.

vbucket ها با استفاده از پروتکل DCP قابلیت replicate شدن در کلاستر را دارند.

با استفاده از Cross Datacenter Replication (XDCR) این دیتابیس برای شما High Availability را فراهم می کند. با این مشخصه می توان اطلاعات bucket ها را به صورت انتخابی در یک کلاستر دیگر replicate کرد.

همچنین با استفاده از server group awareness این امکان فراهم می باشد که چند node از کلاستر را در یک گروه قرار بدهیم و زمانی که زیرساخت با مشکل سنگین مواجه شد از این سرور ها استفاده کنیم.

Cluster Manager:

Cluster manager بر روی تمام نود های کلاستر اجرا می شود و وظیفه اصلی آن نگهداری از process های هر node و هماهنگ سازی عملیات در سطح کلاستر می باشد.

Cluster Manager Architecture:

Cluster manager شامل دو process می شود. Process اول babysitter است که وظیفه نگهداری از سرویس ها Couchbase را دارد. Process دوم ns-server می باشد که مدیریت آن با همان سرویس babysitter است. babysitter تمام سرویس ها را start و monitor می کند و log تمام آنها را در babysitter.log ذخیره می کند. اگر هر کدام از سرویس ها با مشکل مواجه شود babysitter آنرا restart می کند. Babysitter به صورت cluster aware نمی باشد.

Process هایی که babysitter مسئول نگهداری از آنها می باشد به شرح زیر است:

Ns-server: process اصلی cluster manager می باشد و مشارکت یک node در کلاستر را مدیریت می کند.

kv engine: به عنوان بخشی از سرویس Data اجرا می شود و حداقل باید روی یک node در کلاستر نصب شود

Services: یک یا چند سرویس از سرویس های Couchbase را روی node اجرا می کند.

XDCR: این سرویس برای Cross Data-Center Replication (XDCR) می باشد که با سرویس Data نصب می شود منتها در قالب یک process در سطح OS اجرا می شود و خودش را از cluster manager جدا می کند.

view engine: این سرویس برای handle کردن سرویس view استفاده می شود. این سرویس هم به همراه سرویس Data نصب می شود منتها در قالب یک process در سطح OS اجرا می شود و خودش را از cluster manager جدا می کند.

در ادامه به شرح مهمترین process هر کدام می پردازیم:

Ns-server:

ماژول های  این process به شرح زیر می باشند:

REST Administration:

با استفاده از REST API به شما امکان مدیریت Couchbase را می دهد. این ماژول خودش به دو بخش web console یا همان UI و CLI تقسیم می شود..

Authentication:

این ماژول با استفاده از RBAC از منابع node ها محافظت می کند. این فرایند بر اساس credential و مرتبط با role های سیستمی می باش.

Master service:

تمام عملیات هایی که روی کلاستر اثر می گذارد را مانند failover، rebalance، اضافه و حذف کردن bucket را مدیریت می کند. در نظر داشته باشید که در یک کلاستر چند node تنها یک master service مسئول این عملیات در سطح کلاستر می باشد. node ها بین خودشان برای انتخاب master service مذاکرات انجام می دهند.

گاهی اوقات master service را با نام Orchestrator هم می شناسند.

Per Node Services:

وضعیت سلامت node را بررسی می کند همچنین مسئولیت مانیتورینگ process ها و سرویس های آن node و restart کردن آن ها با این سرویس می باشد.

Per Node Bucket Services:

مدیریت عملیات در سطح bucket ها برای node ی که در آن مستقر است به عهده این سرویس می باشد. عملیاتی مانند replication، fail-over, restart و statistics-collection.

Generic Distributed Facilities:

پشتیبانی از node-discovery، alert، replication و heartbeat-transmission به عهده این سرویس می باشد.

Generic Local Facilities:

مسئولیت local configuration-management, libraries, workqueues, logging, clocks, ids,  و  events.

Adding and Removing Nodes:

Master service انتخاب شده مسئول عضو های cluster می باشد. زمانی که topology تغییر پیدا می کند یک سری عملیات باید انجام شود به نحوی load کاری و انجام تغییرات کنترل شوند. این عملیات به شرح زیر می باشد:

  1. Master service تمام node های جدید را برای عضویت در کلاستر موجود به روز رسانی می کند.
  2. Master service عملیات rebalance را شروع می کند و وضعیت vBucket را بررسی می کند.
  3. Node های جدید با استفاده از پروتکل DCP شروع به انتقال اطلاعات می کنند.
  4. زمانی که همه vBucket ها روی node های جدید Active شدند، master service از ارتباط بین node ها مطمئن می شود و این فرایند تا زمانی که فرآیند rebalance کامل شود تکرار می شود.

Node-Failure Detection:

Node های داخل یک کلاستر Couchbase با استفاده از مکانیزم heartbeat وضعیت سلامت خودشان را نشان می دهند. Heartbeat شامل اطلاعات آماری پایه ای از هر node است که میتوان وضعیت هر node را از روی آن بررسی کرد.

Master service اطلاعات ارسالی از heartbeat هر node را پیگیری می کند. اگر automatic failover فعال باشد، وmaster service در یک بازه زمانی مشخص هیچ heartbeat از node ی دریافت نکند به صورت اتوماتیک node را fail شده در نظر میگیرد.

vBucket Distribution:

bucket های این دیتابیس به صورت فیزیکی حاوی 1024 master و 0 یا بیشتر vbucket می باشد. master service مسئول قرار دادن vbucket ها می باشد به نحوی که بتواند بیشترین دسترس پذیری و بهترین عملکرد را ارئه بدهد. با هر تغییر در topology کلاستر vBucket map طبق قوانین زیر دوباره محاسبه می شود.

  1. vBucket اصلی و نسخه کپی آن در دو node مجزا قرار میگیرند.
  2. اگر هر bucket بیشتر از یک کپی داشته باشد، هر کدام در node جدا قرار می گیرد.
  3. اگر یک server group برای نسخه اصلی vbucket ها تعیین شده باشد نسخه کپی آن در server group دیگر قرار میگیرد.

Connectivity:

Couchbase سه نوع ارتباط را کنترل می کند:

  1. Client-to-cluster
  2. Node-to-node
  3. Cluster-to-cluster

همچنین می تواند به برخی از سرویس ها و محصولات دیگر متصل شود.

Client-to-cluster:

Client با استفاده از یکسری access-point های از تعریف شده در Couchbase server به آن متصل می شود. هر کدام پورت مجزایی برای ارتباط clear یا encrypt شده دارد.

Node-to-node:

ارتباط بین node های کلاستر برای مواردی از قبیل replicate کردن اطلاعات، نگهداری از index ها، بررسی وضعیت سلامت node، آگاهی از تغییرات در پیکربندی node و ... انجام می شود. این ارتباط هم می تواند به صورت encrypt شده انجام شود.

Cluster-to-cluster:

دو کلاستر Couchbase از طریق Cross Data Center Replication می توانند با هم ارتباط داشته باشند. به صورت ساده replicate یک bucket در یک datacenter میتواند در کلاستری دیگر در datacenter دیگری باشد. این انتقال با استفاده از XDCR agent که در کلاستر مبدا است و از طریق DCP protocol انجام می شود

Cluster-to-Connector:

Couchbase server می تواند با محصولات دیگر مانند Elasticsearch, Hadoop, Kafka, Spark ارتباط برقرار کند. همچنین درایور های ODBC و JDBC هم برای آن موجود می باشد.