Forwarded from عکس نگار
معرفی JuicsFS: راهکار مدرن برای ذخیره‌سازی توزیع‌شده داده
انتخاب یک راهکار مقیاس‌پذیر و کارآ برای ذخیره توزیع شده فایل‌ها در بسیاری از معماری‌های امروزی سیستم‌های اطلاعاتی یک تصمیم مهم در ایجاد یک زیرساخت ذخیره سازی مطمئن و قابل اتکاست .
برای سال‌ها این نقش را HDFS هدوپ برای سازمان‌ها ایفا می‌کرد که البته برای نیازمندی‌های مدرن طراحی نشده بود و بیشتر ابزار ذخیره سازی هدوپ در عصر نخستین فناوری‌های مرتبط با کلان‌داده بود.
با محبوبیت S3 آمازون، گزینه متن‌باز آن یعنی Mino هم در چند سال اخیر بسیار رایج شده است و به یک De Facto استاندارد برای ایجاد یک زیرساخت ذخیره فایل توزیع شده تبدیل شده است که راه‌اندازی و کار با آن هم بسیار ساده است.
اما اگر سیستمی دارید که بخشی ازفایلهای آن در کلاد (S3، Google Cloud Storage، Azure Blob) و بخشی دیگر در سرورهای محلی و بخشی در سرورهای تخصصی استوریج مانند سرویس‌های S3 که امروزه اکثر شرکت‌های ایرانی هم ارائه می‌دهند، قرار گرفته است و به یک واسط استاندارد و یکپارچه برای دسترسی به تمام این استوریج‌ها نیاز دارید، JuiceFS برای شما طراحی شده است.
💡 مزایای کلیدی JuicsFS
• سازگاری کامل با POSIX: امکان استفاده مانند یک سیستم فایل معمولی
• پشتیبانی از انواع ذخیره‌سازی ابری
• عملکرد بالا: بهره‌گیری از کش محلی برای بهبود سرعت خواندن و نوشتن (واینکه با زبان Go نوشته شده است)
• قابلیت اطمینان و مقیاس‌پذیری: امکان گسترش آسان با رشد حجم داده‌ها
آدرس گیت‌هاب پروژه : https://github.com/juicedata/juicefs
سایت اصلی JuicFS
https://juicefs.com/en
🔑 JuiceFS رایگان و متن‌باز است و جامعه فعالی از توسعه‌دهندگان از آن پشتیبانی می‌کنند.
پی‌نوشت:
یکی از خوانندگان عزیز این مطلب در لینکدین هم نظری راجع به این پروژه داشتند که بهتر است دوستان حتما با دقت آنرا بررسی کنند :
»
#DataEngineering #BigData #Cloud #OpenSource #DistributedSystems
انتخاب یک راهکار مقیاس‌پذیر و کارآ برای ذخیره توزیع شده فایل‌ها در بسیاری از معماری‌های امروزی سیستم‌های اطلاعاتی یک تصمیم مهم در ایجاد یک زیرساخت ذخیره سازی مطمئن و قابل اتکاست .
برای سال‌ها این نقش را HDFS هدوپ برای سازمان‌ها ایفا می‌کرد که البته برای نیازمندی‌های مدرن طراحی نشده بود و بیشتر ابزار ذخیره سازی هدوپ در عصر نخستین فناوری‌های مرتبط با کلان‌داده بود.
با محبوبیت S3 آمازون، گزینه متن‌باز آن یعنی Mino هم در چند سال اخیر بسیار رایج شده است و به یک De Facto استاندارد برای ایجاد یک زیرساخت ذخیره فایل توزیع شده تبدیل شده است که راه‌اندازی و کار با آن هم بسیار ساده است.
اما اگر سیستمی دارید که بخشی ازفایلهای آن در کلاد (S3، Google Cloud Storage، Azure Blob) و بخشی دیگر در سرورهای محلی و بخشی در سرورهای تخصصی استوریج مانند سرویس‌های S3 که امروزه اکثر شرکت‌های ایرانی هم ارائه می‌دهند، قرار گرفته است و به یک واسط استاندارد و یکپارچه برای دسترسی به تمام این استوریج‌ها نیاز دارید، JuiceFS برای شما طراحی شده است.
💡 مزایای کلیدی JuicsFS
• سازگاری کامل با POSIX: امکان استفاده مانند یک سیستم فایل معمولی
• پشتیبانی از انواع ذخیره‌سازی ابری
• عملکرد بالا: بهره‌گیری از کش محلی برای بهبود سرعت خواندن و نوشتن (واینکه با زبان Go نوشته شده است)
• قابلیت اطمینان و مقیاس‌پذیری: امکان گسترش آسان با رشد حجم داده‌ها
آدرس گیت‌هاب پروژه : https://github.com/juicedata/juicefs
سایت اصلی JuicFS
https://juicefs.com/en
🔑 JuiceFS رایگان و متن‌باز است و جامعه فعالی از توسعه‌دهندگان از آن پشتیبانی می‌کنند.
پی‌نوشت:
یکی از خوانندگان عزیز این مطلب در لینکدین هم نظری راجع به این پروژه داشتند که بهتر است دوستان حتما با دقت آنرا بررسی کنند :
این فایل سیستم در نسخه رایگان از Distributed Data Cache استفاده نمی کنه همچنین عدم پشتیبانی از ACL و کربروس و Apache Ranger یعینی عدم پشتیبانی از کلیه راه کارهای امنیت . در سازمان های بزرگ این این موارد نباشه اصلا توصیه نمیشه ولی شاید برای سازمان هایی که بخوان امنیت را در لایه application کنترل کنن شاید مفید باشه
»
#DataEngineering #BigData #Cloud #OpenSource #DistributedSystems
👍3
چرا مایکروسافت برای Clarity, دیتابیس تحلیلی کلیک‌هوس را برگزید؟
این پست ترجمه‌ای است از پست رسمی تیم ClickHouse درباره انتخاب این پایگاه داده قدرتمند توسط مایکروسافت.
پست اصلی :
https://www.linkedin.com/posts/clickhouseinc_when-microsoft-made-clarity-free-for-everyone-activity-7325580280390451200-fV_M
زمانی که مایکروسافت ابزار Clarity را به‌صورت رایگان برای عموم عرضه کرد، می‌دانست که باید این سرویس را به سرعت و در مقیاسی عظیم گسترش دهد — پردازش صدها تریلیون رویداد، صدها پتابایت داده، و میلیون‌ها پروژه در سطح جهانی.
برای چنین زیرساختی، انتخاب موتور تحلیلی بسیار مهم بود.
مایکروسافت پس از ارزیابی گزینه‌هایی مانند Elasticsearch و Apache Spark، در نهایت با تحقیقاتی گسترده و تست‌های متعدد، ClickHouse را برگزید.
چرا ClickHouse؟
در اکتبر ۲۰۲۰، Clarity با ClickHouse در قلب خود راه‌اندازی شد. این تصمیم حاصل هفته‌ها آزمایش، بررسی‌های عمیق، سنجش هزینه‌ها و عملکردها، و انتخابی مبتنی بر داده بود.
دلایل اصلی:
📥 عملکرد بارگذاری (Ingestion): موتور MergeTree در ClickHouse، نرخ ورودی بسیار بالایی را پشتیبانی می‌کند که کاملاً با نیاز بار عظیم Clarity هم‌خوانی دارد.
⚡ عملکرد کوئری: پرس‌وجو روی میلیاردها ردیف در کسری از ثانیه، با کارایی فوق‌العاده. این عملکرد سریع، نیاز به منابع پردازشی بیشتر را حذف و هزینه‌ها را کاهش می‌دهد.
💾 بهره‌وری در ذخیره‌سازی: ساختار ستونی و فشرده‌سازی پیشرفته، موجب صرفه‌جویی چشم‌گیر در فضای دیسک می‌شود. امکان تعریف دیسک‌های گرم و سرد نیز برای کاهش بیشتر هزینه‌ها فراهم است.
📈 مقیاس‌پذیری افقی: ClickHouse به‌صورت master-master توزیع شده و از replication پشتیبانی می‌کند. این یعنی مقیاس‌پذیری روان و آسان هنگام افزایش ترافیک.
🤝 جامعه‌ی متن‌باز و فعال: انتشار منظم نسخه‌ها، پاسخ‌گویی سریع در GitHub و تلگرام، و پشتیبانی قدرتمند. جالب‌تر اینکه تیم مایکروسافت نیز به پروژه کمک کرده و نام خود را در جدول system.contributors ثبت کرده‌اند!
و در نهایت، همان‌طور که در گزارش رسمی مایکروسافت آمده است:
> Compared to our POC system, ClickHouse outperformed Elastic Search and Spark in every aspect. Heat map generation became an instantaneous task to do, and it was even orders of magnitude cheaper to run. This is the reason why many products have migrated from Elastic Search to ClickHouse, experiencing significant enhancements in their services as a result.
آدرس مقاله اصلی مایکروسافت :
https://clarity-blogs-hbh0gkgebxgwfkgd.westus2-01.azurewebsites.net/why-microsoft-clarity-chose-clickhouse/
#ClickHouse #Microsoft #Clarity #داده_های_انبوه #تحلیل_داده #پایگاه_داده #BigData #DataEngineering #ElasticSearch #Spark #CloudArchitecture #OpenSource #مقیاس‌پذیری #StorageOptimization #DatabasePerformance #DistributedSystems
این پست ترجمه‌ای است از پست رسمی تیم ClickHouse درباره انتخاب این پایگاه داده قدرتمند توسط مایکروسافت.
پست اصلی :
https://www.linkedin.com/posts/clickhouseinc_when-microsoft-made-clarity-free-for-everyone-activity-7325580280390451200-fV_M
زمانی که مایکروسافت ابزار Clarity را به‌صورت رایگان برای عموم عرضه کرد، می‌دانست که باید این سرویس را به سرعت و در مقیاسی عظیم گسترش دهد — پردازش صدها تریلیون رویداد، صدها پتابایت داده، و میلیون‌ها پروژه در سطح جهانی.
برای چنین زیرساختی، انتخاب موتور تحلیلی بسیار مهم بود.
مایکروسافت پس از ارزیابی گزینه‌هایی مانند Elasticsearch و Apache Spark، در نهایت با تحقیقاتی گسترده و تست‌های متعدد، ClickHouse را برگزید.
چرا ClickHouse؟
در اکتبر ۲۰۲۰، Clarity با ClickHouse در قلب خود راه‌اندازی شد. این تصمیم حاصل هفته‌ها آزمایش، بررسی‌های عمیق، سنجش هزینه‌ها و عملکردها، و انتخابی مبتنی بر داده بود.
دلایل اصلی:
📥 عملکرد بارگذاری (Ingestion): موتور MergeTree در ClickHouse، نرخ ورودی بسیار بالایی را پشتیبانی می‌کند که کاملاً با نیاز بار عظیم Clarity هم‌خوانی دارد.
⚡ عملکرد کوئری: پرس‌وجو روی میلیاردها ردیف در کسری از ثانیه، با کارایی فوق‌العاده. این عملکرد سریع، نیاز به منابع پردازشی بیشتر را حذف و هزینه‌ها را کاهش می‌دهد.
💾 بهره‌وری در ذخیره‌سازی: ساختار ستونی و فشرده‌سازی پیشرفته، موجب صرفه‌جویی چشم‌گیر در فضای دیسک می‌شود. امکان تعریف دیسک‌های گرم و سرد نیز برای کاهش بیشتر هزینه‌ها فراهم است.
📈 مقیاس‌پذیری افقی: ClickHouse به‌صورت master-master توزیع شده و از replication پشتیبانی می‌کند. این یعنی مقیاس‌پذیری روان و آسان هنگام افزایش ترافیک.
🤝 جامعه‌ی متن‌باز و فعال: انتشار منظم نسخه‌ها، پاسخ‌گویی سریع در GitHub و تلگرام، و پشتیبانی قدرتمند. جالب‌تر اینکه تیم مایکروسافت نیز به پروژه کمک کرده و نام خود را در جدول system.contributors ثبت کرده‌اند!
و در نهایت، همان‌طور که در گزارش رسمی مایکروسافت آمده است:
> Compared to our POC system, ClickHouse outperformed Elastic Search and Spark in every aspect. Heat map generation became an instantaneous task to do, and it was even orders of magnitude cheaper to run. This is the reason why many products have migrated from Elastic Search to ClickHouse, experiencing significant enhancements in their services as a result.
آدرس مقاله اصلی مایکروسافت :
https://clarity-blogs-hbh0gkgebxgwfkgd.westus2-01.azurewebsites.net/why-microsoft-clarity-chose-clickhouse/
#ClickHouse #Microsoft #Clarity #داده_های_انبوه #تحلیل_داده #پایگاه_داده #BigData #DataEngineering #ElasticSearch #Spark #CloudArchitecture #OpenSource #مقیاس‌پذیری #StorageOptimization #DatabasePerformance #DistributedSystems
Linkedin
When Microsoft made Clarity free for everyone, they knew it had to scale -… | ClickHouse
When Microsoft made Clarity free for everyone, they knew it had to scale - fast - to hundreds of trillions of events, hundreds of petabytes of data, and millions of projects.
Their choice to power these workloads? ClickHouse. After testing Elasticsearch…
Their choice to power these workloads? ClickHouse. After testing Elasticsearch…
❤3🔥1
چرا UUID7 و ULID گزینه‌های بهتری برای کلیدهای اصلی در پایگاه داده هستند؟
در طراحی پایگاه‌های داده، انتخاب نوع شناسه (ID) یکی از تصمیم‌های کلیدی است که می‌تواند تأثیر زیادی بر عملکرد، مقیاس‌پذیری و امنیت سیستم داشته باشد.
در سناریوهایی مثل سیستم‌های توزیع‌شده، APIهای پرترافیک یا صفحات محصول در وب‌سایت‌ها که نیاز به درج سریع داده و جلوگیری از افشای الگوی رکوردها وجود دارد، استفاده از کلیدهای auto-increment معمولاً گزینه مناسبی نیست. چون:
⛔️باعث قفل شدن جدول در شرایط همزمانی بالا می‌شود،
⛔️امکان حدس زدن تعداد یا ترتیب رکوردها را فراهم می‌کند.
💡 راه‌حل سنتی چیست؟
استفاده از UUID (نسخه ۴) به‌عنوان کلید اصلی مزایای خوبی دارد: یکتایی جهانی بدون نیاز به هماهنگی بین سرورها، مناسب برای محیط‌های توزیع‌شده، و جلوگیری از افشای الگوهای داده. اما یک مشکل جدی دارد.
🔍 چرا UUID تصادفی (مثلاً UUIDv4) در دیتابیس‌ها عملکرد خوبی ندارد؟
اکثر پایگاه‌های داده رابطه‌ای مانند PostgreSQL، MySQL و SQL Server برای ایندکس‌گذاری — مخصوصاً روی کلید اصلی — از ساختاری به‌نام B-Tree (Balanced Tree) استفاده می‌کنند.
این ساختار کمک می‌کند:
✳️جستجوی کلیدها با پیچیدگی O(log n) انجام شود (سریع و مقیاس‌پذیر)،
✳️داده‌ها به‌صورت مرتب نگه داشته شوند،
✳️ و درج، حذف یا به‌روزرسانی به‌شکل کارآمد مدیریت شود.
اما مشکل از جایی شروع می‌شود که کلیدهایی با ترتیب تصادفی (مثل UUIDv4) در جدول وارد می‌شوند.
📉 چه اتفاقی می‌افتد؟
وقتی داده‌های زیادی با کلید تصادفی وارد جدول می‌شوند:
⛔️ دیتابیس نمی‌تواند آن‌ها را در انتهای ساختار درختی اضافه کند (مثل auto-increment IDs)،
⛔️ باید آن‌ها را بین صفحات مختلف B-Tree پراکنده کند،
⛔️ این پراکندگی باعث عملیات مکرر Page Split (شکستن صفحات)، جابه‌جایی نودها و بازچینش ساختار درختی می‌شود.
🧨 نتیجه؟
🧱کند شدن محسوس عملیات درج (INSERT)،
🧱 مصرف بالای I/O و حافظه،
🧱 کاهش عملکرد کلی سیستم در سناریوهای پرترافیک.
✅ راه‌حل‌های مدرن: UUID7 و ULID
برای رفع این مشکلات، دو استاندارد جدید معرفی شده‌اند:
🔹 استاندارد ULID (Lexicographically sortable): ترکیبی از timestamp و داده تصادفی
🔹 استاندارد UUIDv7: نسخه‌ای از UUID با ترتیب زمانی، سازگار با استاندارد UUID
مزیت اصلی این دو چیست؟
🔸 با حفظ یکتایی و امنیت، کلیدها به‌صورت ترتیبی در ایندکس درج می‌شوند.
🔸 این یعنی:
✅کاهش شدید Page Split و پراکندگی
✅بهبود درج‌های پرترافیک
✅جست‌وجوی سریع‌تر بر اساس بازه‌های زمانی
📊 چه زمانی از هرکدام استفاده کنیم؟
اگر خوانایی و طول کوتاه‌تر مهم است → ULID
اگر سازگاری با UUID استاندارد اهمیت دارد → UUIDv7
📐 قالب ULID
قالب ULID یک رشته ۲۶ نویسه‌ای است که با Crockford’s Base32 کدگذاری می‌شود (حروف I, L, O, U حذف شده‌اند تا اشتباه نشوند).
→ طول: ۲۶ نویسه - کاراکترهای ابتدایی مهرزمان هستند.
→ مثال: 01AN4Z07BY79KA1307SR9X4MV3
📐 قالب UUIDv7
→ نمایش به‌صورت استاندارد UUID در مبنای ۱۶ (hex) با خط تیره
→ طول شامل خط تیره: ۳۶ نویسه - کاراکترهای ابتدایی مهرزمان هستند.
→ قالب: 8-4-4-4-12
→ مثال: 017f45e0-7e1a-7a3f-8bbc-4dbf7e6d9c3a
→ طول بدون خط تیره: ۳۲ نویسه hex
#Database #Backend #DistributedSystems #UUID #ULID #PostgreSQL #SystemDesign #Performance #مهندسی_داده
در طراحی پایگاه‌های داده، انتخاب نوع شناسه (ID) یکی از تصمیم‌های کلیدی است که می‌تواند تأثیر زیادی بر عملکرد، مقیاس‌پذیری و امنیت سیستم داشته باشد.
در سناریوهایی مثل سیستم‌های توزیع‌شده، APIهای پرترافیک یا صفحات محصول در وب‌سایت‌ها که نیاز به درج سریع داده و جلوگیری از افشای الگوی رکوردها وجود دارد، استفاده از کلیدهای auto-increment معمولاً گزینه مناسبی نیست. چون:
⛔️باعث قفل شدن جدول در شرایط همزمانی بالا می‌شود،
⛔️امکان حدس زدن تعداد یا ترتیب رکوردها را فراهم می‌کند.
💡 راه‌حل سنتی چیست؟
استفاده از UUID (نسخه ۴) به‌عنوان کلید اصلی مزایای خوبی دارد: یکتایی جهانی بدون نیاز به هماهنگی بین سرورها، مناسب برای محیط‌های توزیع‌شده، و جلوگیری از افشای الگوهای داده. اما یک مشکل جدی دارد.
🔍 چرا UUID تصادفی (مثلاً UUIDv4) در دیتابیس‌ها عملکرد خوبی ندارد؟
اکثر پایگاه‌های داده رابطه‌ای مانند PostgreSQL، MySQL و SQL Server برای ایندکس‌گذاری — مخصوصاً روی کلید اصلی — از ساختاری به‌نام B-Tree (Balanced Tree) استفاده می‌کنند.
این ساختار کمک می‌کند:
✳️جستجوی کلیدها با پیچیدگی O(log n) انجام شود (سریع و مقیاس‌پذیر)،
✳️داده‌ها به‌صورت مرتب نگه داشته شوند،
✳️ و درج، حذف یا به‌روزرسانی به‌شکل کارآمد مدیریت شود.
اما مشکل از جایی شروع می‌شود که کلیدهایی با ترتیب تصادفی (مثل UUIDv4) در جدول وارد می‌شوند.
📉 چه اتفاقی می‌افتد؟
وقتی داده‌های زیادی با کلید تصادفی وارد جدول می‌شوند:
⛔️ دیتابیس نمی‌تواند آن‌ها را در انتهای ساختار درختی اضافه کند (مثل auto-increment IDs)،
⛔️ باید آن‌ها را بین صفحات مختلف B-Tree پراکنده کند،
⛔️ این پراکندگی باعث عملیات مکرر Page Split (شکستن صفحات)، جابه‌جایی نودها و بازچینش ساختار درختی می‌شود.
🧨 نتیجه؟
🧱کند شدن محسوس عملیات درج (INSERT)،
🧱 مصرف بالای I/O و حافظه،
🧱 کاهش عملکرد کلی سیستم در سناریوهای پرترافیک.
✅ راه‌حل‌های مدرن: UUID7 و ULID
برای رفع این مشکلات، دو استاندارد جدید معرفی شده‌اند:
🔹 استاندارد ULID (Lexicographically sortable): ترکیبی از timestamp و داده تصادفی
🔹 استاندارد UUIDv7: نسخه‌ای از UUID با ترتیب زمانی، سازگار با استاندارد UUID
مزیت اصلی این دو چیست؟
🔸 با حفظ یکتایی و امنیت، کلیدها به‌صورت ترتیبی در ایندکس درج می‌شوند.
🔸 این یعنی:
✅کاهش شدید Page Split و پراکندگی
✅بهبود درج‌های پرترافیک
✅جست‌وجوی سریع‌تر بر اساس بازه‌های زمانی
📊 چه زمانی از هرکدام استفاده کنیم؟
اگر خوانایی و طول کوتاه‌تر مهم است → ULID
اگر سازگاری با UUID استاندارد اهمیت دارد → UUIDv7
📐 قالب ULID
قالب ULID یک رشته ۲۶ نویسه‌ای است که با Crockford’s Base32 کدگذاری می‌شود (حروف I, L, O, U حذف شده‌اند تا اشتباه نشوند).
→ طول: ۲۶ نویسه - کاراکترهای ابتدایی مهرزمان هستند.
→ مثال: 01AN4Z07BY79KA1307SR9X4MV3
📐 قالب UUIDv7
→ نمایش به‌صورت استاندارد UUID در مبنای ۱۶ (hex) با خط تیره
→ طول شامل خط تیره: ۳۶ نویسه - کاراکترهای ابتدایی مهرزمان هستند.
→ قالب: 8-4-4-4-12
→ مثال: 017f45e0-7e1a-7a3f-8bbc-4dbf7e6d9c3a
→ طول بدون خط تیره: ۳۲ نویسه hex
بنابراین UUID7 طول بیشتری نسبت به ULID دارد اما چون با استاندارد UUID سازگاراست، برای سیستم‌های موجود گزینه بهتری است.
#Database #Backend #DistributedSystems #UUID #ULID #PostgreSQL #SystemDesign #Performance #مهندسی_داده
👍8❤1