فراخوانی تمام اطلاعات چند جدول در حداکثر سرعت

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

فرض کنید در یک پروژه فونیکس با رندر html هستیم . کاربر می خواهد یک مطلب با دکمه جدید شروع به ارسال کند . که با فیلد های زیر رو در رو می شود

09%20am

به عنوان مثال فکر کنید می خواهد انتخاب کند در کدام مجموعه این مطلب ارسال شود . حالا علاوه بر مجموعه ۵ فیلد بالا هست که با زدن اون مثلث :small_red_triangle_down: باید لیست مجموعه ها و آیدی هاشون بیاد کاربر یکی رو انتخاب کنه

پس در کل من ۶ فیلد دارم که باید اسم و آیدیشون از ۶ جدول متفاوت گرفته شود شما در اینجا چطور اینکارو می کنید

آیا ۶ تسک در الکسیر درست می کنید و می فرستید به هر جدول و می گویید هر کدام را تونست پیدا کند بریزد در یک آرایه و در آخر شما از اون آرایه استفاده می کنید ؟ یا راه دیگیری برای این کار دارید .

در این بخش سرعت بسیار پارامتر مهمی برای بنده هست . چون امکان دارد این فیلد ها به تعداد ۱۰۰ عدد در یک پست برسند

با تشکر

به روز رسانی

برای اطلاعات بیشتر دیتابیس بنده با پستگرس درست شده . دیتابیس بر روی یک سرویس هست و همینطور این دیتابیس فقط مخصوص میکروسرویس cms من هست.

بنده برای کار با دیتابیس با Ecto کار می کنم کوآری خودم نمی نویسم در حقیقت زیاد هم آشنایی ندارم فکر کنم Ecto کامل مشکلاتمو حل می کنه

حجم داده ها در این ۶ فیلد خیلی کم هست فکر کنید کاربر مگه چند مجموعه تو سایتش درست می کنه خیلی زیاد بشه هر کدوم از جداول ها داخلش حداکثر ۱۰۰ رکورد وجود داره در کل ۶۰۰ رکورد که دو سطونش نیاز هست آیدی و اسم .

این دسته از جداول بنده به هم ارتباطی ندارند یعنی رلیشن ندارند .

در آخر باید این رو خدمت دوستان بگم این یک وبسرویس تقریبا متوسط هست که برای خودمه به شدت در حال یادگیری هستم به همین منظور تا آخرین حرکت که حرکت برسلی باشه :grin: نیازمند به سرعت هستم .

در مورد کش کردن در ردیس و … هم فکرم رسیده ولی خیلی پیچیدگی برام ایجاد می کنه در یک مورد کاربر و لاگین توکن دادن کش کردم تا ۱ هفته سر درد داشتم

1 پسندیده

تجربه فوئنیکس ندارم متاسفانه … ولی چند تا مسئله خیلی مهمه . .اول اینکه حجم دیتا تو جدول هاتون چقدره … دوم اینکه دیتابیستون SQL هست یا نوع دیگه … سوم اینکه سیستمتون توزیع شده هست یا سینگل نود . .

ایندکس گذاشتن تو سری SQL خیلی مهمه …
دوم اگه به دیتابیس مورد استفاده تون مسلط هستین به فانشنالیتیش … میتونید استور پراسیجر بنویسید …

سوم … اگر منابع کافی دارید … سریع ترین راه تا رسیدن به مرز بحرانی (ک ormها عمدتا استفادش میکنن) اینه ک اطلاعات رو واکشی کنید … و روی رم کار های فیلترینگ و سورت و این حرفا رو انجام بدید … ک 100% سرعت فوق العاده ای بهتون میده …

و مهم تر از همه اینه ک … جدول ها و دیتابیس تونو بهینه طراحی کردید یا نه … یه دیتابیس بهینه ک ریلیشن هاش درست هستن و کمترین میزان null و default رو داره … سریع تر بهتون جواب میده …

و نکته اخر اینه ک . .سرعت واکشی تون الان چقدره و میخایید چقد ارتقاش بدید … (گاهی وسواس زیاد سر میلی ثانیه کار دست ادم میده :smiley: )

1 پسندیده

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

بجز کش کردن من دو راه به فکرم اومد

۱. این بود که ۶ جدول رو رلیشن کنم که یک کو آری درست کنم که این ۶ جدول رو بیاند از هر کدوم آیدی و اسمشون بیاره و با یک درخواست بگیرمش . بعد یادم اومد که اصلا این جداول به هم ربطی ندارند بر اساس چی اصلا رلیشن کنم ؟ که تقریبا پیش خودم کنسلش کردم

۲. راه دوم اینکه از خاصیت بسیار دوست داشتنی الکسیر استفاده کنم اونم تسک سوپروایزرش هست بجای یک درخواست ۶ درخواست بفرستم و هر کدوم از درخواست ها ردیف شد بیاد در یک آرایه و استفادش کنم

منبع : https://hexdocs.pm/elixir/Task.Supervisor.html

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

ممنون از شما

1 پسندیده

بسیار عالی … لینکی ک دادید رو رفتم گذرا دیدم … تسک های اسینک میسازه … ک هرکدوم مستقل میرن جلو

راه خیلی جالبی هستش و خوب به نظر میاد …

نکته ای ک باید بگم اینه ک … چون گفتین درحال یادگیری هستین و شخصی هست پروژه و میزان دیتا خیلی کمه … یکم تصمیم گیری و پیشنهاد دادن رو مشکل میکنه (فک میکنم شما هم مثل من به perfectionism دچار هستین :joy: و میخایید بهترین راه حل و عمقی ترینش رو اول پیدا کنید و بعد پیش برید) … ک خب من سر همین قضیه . .یکی از پروداکشن هام بشدت طولانی شد … و زمان زیادی از دستم رفت…

به نظرم بهتره راه حل های مد نظرتونو امتحان کنیدو خودتون بنچمارک بگیرید … و دیتاست های بزرگ به پروژه و دیتابیس اد کنید تا ببینید ک کدومش بهتر جواب میده …

کش ها به نظر من بزرگترین دستاورد بشر بودن :slight_smile: تا حدی ک از کندترین زبان ها و تکنولوژی ها میشه با کش ها …حداکثر سرعت و استفاده از منابع رو برد . … و این هم به چشم نمیاد و مورد استفاده نمیگیره مگر روی پروداکشنی ک بزرگ شده و پرفورمنس و بهینگی بشدت به چشم میاد … و در آخر ک گفتین زیاد اهل کوئری زدن نیستین … طبیعیه … یه کار بزرگ کار یک نفر نمیتونه باشه و توانایی یک نفر محدود هست و متخصص بودن تو یه چیزی … و جمع شدن این متخصص ها دور هم هست ک یه پروژه بزرگ و عالی رو میسازن …

موفق باشید .

1 پسندیده

بحثش که پیش اومده بگم من شبا چندین ۱۰ باری خواب دیدم هرکاری می کردم پروژم ۱ میلی ثانیه سرعتش بیشتر نمی شد :grin::grin:

خیلی ممنونم از نظراتتون و تشکر و همینطور باز منتظر نظرات دوستان هم موازی انجام پروژه به وسیله خودم هستم

فقط برای تکمیل کردن بحث

این نمونه قدیمی بود که کشیدم از همین چیزی که دارم می نویسم . موردی که باعث شد به کش فکر نکنم علاوه بر پیچیدگیش این بود که امکان داشت من در میکرو سرویس دومی Redis نداشته باشم . چون هر کانتینرم یا هر سرویسم دیتابیس پستگرس جدا و Redis جدا داره .

تشکر خیلی زیاد از شما :rose::rose:

1 پسندیده

اینی ک کشیدید صرفا توزیع شدگی و کپی از هر سرویس رو نشون میده :thinking: میکرو هاتون باهم در ارتباط نیستن ؟؟‌
اصولا میکروسرویس بخاطر این هست ک شما همشونو تکرار نکنید … یا همشونو یکپارچه نکنید … هرکدوم از سرویس ها امکاناتی دارن … ک باهم در ارتباطن … و اگه چیزی نیاز داشت ک نداشت … به سرویس بعدی ریکوئست میزنه و ازش میگیره …

1 پسندیده

هر کانتینر که در سمت چپ تصویر هست هر کدوم برای یک کاری هست به عنوان مثال بخش لاگین یک کانتینر و بخش ( فروشگاه و سیستم مدیریت محتوام ) یک کانیتنر هست و بخش پشتیبانی انبارم هم یک کانیتنر دیگه .

خیر هیچ کدوم از میکرو ها مستقیم با هم در ارتباط نیستند اگر بخواند ازهم اطلاعاتی بگیرند به API درخواست ارسال می کنند و اون API می ره از میکرو مورد نظر می گیره و برگشت می ده به اون میکرویی که درخواست ارسال کرده

من چیزی رو کپی نکردم یا صحبت شما رو خوب متوجه نشدم :thinking:

اتصال همه میکرو ها به واسطه API هست که کشیدم که یک کانتینر جدا هست هست

1 پسندیده

خب اگر اینطوره … اصلا نیاز نیست دیتابیس کنار همشون باشه … یا ردیس هم …
اینها کانتینر جدا میتونن باشن … و به سایر سرویس ها خدمات بدن با api … :thinking:

1 پسندیده

خوب اگر دیتابیس برای هرکدومش نباشه . ممکنه اپلیکیشن من بخش سیستم مدیریت محتوای من رو خیلی درگیر کنه و خیلی به دیتابیس بره و درخواست هارو برای کاربر بیاره و حتی ممکنه این کار باعث کم شدن سرعت در مثلا بخش پشتیبانی و فروشم داشته باشم . در صورتی که بخش فروش و پشتیبانی من اصلا ربطی به سیستم مدیریت محتوای من نداره

به همین منظور با مشورت از دوستان داخل همین انجمن اومدم دیتابیسشون رو جدا کردم که استقلال کامل خودشو داشته باشه

البته خدمت شما دوست عزیزم باید بگم که این مثال ها کوچیک نشون می ده من انقدر سیستم رو ریز نکردم که بعدا دچار مشکل بشم بلکه بخش های خیلی بزرگ که استقلال کامل دارند و ربطی به اون یکی ندارند رو جدا کردم

1 پسندیده

این صحیحه … اما این حد از گسستگی هم مشکل ایجاد میکنه… مثل همون چیزی ک فرمودید …
و الان به قدری شکسته و بی ارتباط هستن ک شما مجبورید هرتکنولوژی رو رو همشون نصب کنید … درحالی ک میتونید یه نود کش وسطشون بزارید … تا سربار روی نود دیتابیس رو کم کنه … و خود نود دیتابیس رو چندتایی کنید اما مستقل بازم …

1 پسندیده

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

یعنی ارتباط همشون فقط توکن و اطلاعات کاربری و دو تای دیگه با هم اصلا ارتباط نیستند و هر کدومشون هم به مرور بسیار بزرگ می شند

به عنوان مثال یکی از این میکرو ها الان در اون بخش پشتیبانی هست به زودی بخش مدیرتی پروژه و همینطور مثال مدیریت تسک هم اضافه می شه که حتی در ۹۵ درصد :grin: که نمی دونم این آمار کجا آوردم کاربرانشونم متفاوتند ممکنه این افراد استفاده کننده از مثلا میکرو دو استفاده نکنند

خیلی ممنونم نظراتتون می گید و بنده جز تشکر چیزی از دستم بر نمی یاد :disappointed_relieved:
باز اگر نظری در این رابطه دارید بسیار ممنون می شم بفرمایید از تجربه شما استفاده کنیم :rose::rose:

1 پسندیده

خواهش میکنم دوست عزیز :slightly_smiling_face: کار بخصوصی نکردم …
طراحی و ایجاد میکروسرویس دردسرای خودشو داره و هرکسی هم معماری متفاوتی میزنه …

تو جدا کردن نود دیتابیس چند تا نکته خیلی مهمن…
اول اینکه نود دیتابیس میتونه اصلا پروسس نکنه … و صرفا جنبه واکشی داشته باشه و داده هارو به میکرو های شما بفرسته و شما اونجا پروسس کنید و نتایج رو بدید به کاربر …

جدا کردن نود کش هم همینطوره …

حالا یه مسئله ک مطرحه اینه ک … اگر میخایید سربار از یکی کم بشه و رو یکی ک استفادش زیاده باشه … لود بالانسر هم مورد نیازه … تا ترافیک و پهنا رو براتون تقسیم کنه …

1 پسندیده

در این مورد لود بالانسر هنوز موفق به تحقیق نشدم و اطلاعاتی ازش ندارم فقط در آموزش های داکر که دیدیم یک چیزی به نام سو آرم رو به گوشم خورد و یک چند ساعتی روش مطالعه کردم که هیچی هم یادم نیست :rofl:

منظور شما همینه ؟

1 پسندیده

احسنت : ) یکی از نمونه های خوب لود بالانسینگ و تسک اسکژولینگ داکر سوارم هست … اما تکنولوژی زیاده … مثل HAproxy , NginX و… …

اینم اخرین پیشنهاد من

به نظرم کش هارو کنار هر سرویس میزاشتید و db جدا میشد … خیلی تو سرعت و بهینگی تون تاثیر میزاشت . .

این یه تصویر از TAO فیس بوکه

image

آرزوی موفقیت میکنم واستون :cherry_blossom::rose:

1 پسندیده

یه نکته هم اضافه کنم … البته از بزرگانه … من در حدی نیستم راجبه این نظری بدم :sweat_smile:
تا جای ممکن و اگر تکی کار میکنید و یا تیم تون انقد منسجم و مچ هست معماری رو مونولیتیک بردارید …

میکروسرویس با بزرگ شدن سیستم … مدیریتش وحشتناک سخت میشه …

1 پسندیده

اینو متوجه نشدم چطور معماری هست ؟ البته جستجوش می کنم حتما . ما در کل سه نفریم دو نفر الکسیر کاریم .

حتما . خیلی از بخش ها کش کردم :rose:

1 پسندیده

مونولیتیک همون معماری یکپارچه و عادی هستش .

1 پسندیده
1 پسندیده

من با اجازتون چون بحثش قبلا هم تو انجمن شد و جالب بود من اینجا یک پست جدید درست کردم

1 پسندیده

در میکروسرویس ها میتونی database نداشته باشی ولی هرگز دو microservice نباید با یک database کار کنن این یکی از اصول مقدماتی
Service Oriented Architecture هستش
راجبه سوال اول هم چه با تسک چه request sync بزنی مشکل performance نداری این مورد انقدر ساده هست که تا وقتی مشکل نشده بهش فکر نکن

1 پسندیده