Composition در واقع اشاره می کند به روابط بین Object ها در فضای Object-Oriented. همچنین یکی از اصول طراحی با عنوان Favor composition over inheritance در همین زمینه برای رسیدن به Polymorphic behavior و Code reuse مطرح است. مثال های لینک زیر را بررسی کنید:
منظور از Composition الگوی طراحیه؟
پاسخ Jimmy Bogard را در رابطه با این موضوع مطالعه کنید:
https://github.com/jbogard/MediatR/issues/434#issuecomment-527446360
The indirection of a handler is good at the application level, but just got confusing once we got inside a handler (and it introduced coupling)
پیشنهاد می کنم برای Reusability از Composition بهره بگیرید و قسمتی که لازم است به صورت مشترک استفاده شود را در قالب یکسری کلاس Refactor کرده و استفاده کنید.
پیشنهاد میکنم، ابتدا با ابزاری مثل benchmarkdotnet نرخ دریافت و ذخیره رو اندازه‌گیری کنید. بعد ببینیم آیا گلوگاهی وجود داره یا نه، و اگر داره کجاست. چون الان هر بحث و راه‌حل پیشنهادی مثل پیشنهاد دکوراسیون یک اتاق کاملا تاریک است!
شاید لازم باشه بعدش پرفرمنس دیسک دیتابیس سرورتون رو با ابزاری مثل diskspd بسنجید. یا به فکر in-memory oltp روی slq server باشید که سرعت درج داده رو کاهش بده.
استفاده از Multithreading هم حتمن یکی از پیشنهادهای ضروری و خوب است.
پیشنهاد میکنم یک کافکا یا rabbit بالا بیارید و کالاهایی که crawl کردید رو ابتدا روی صف قرار بدید(fire and forget) و یک background service داشته باشید که به صف گوش بده و دیتا رو به دیتابیس انتقال بدید.
مثالی با rabbit
کجا می تونم اطلاعاتی در مورد این روش پیدا کنم؟
اگر مشکل در ذخیره و نمایش داده ها به صورت آنی ندارید، پشنهاد میکنم یک message broker در سر راه این معماری قرار بدید تا مشکل که بیان کردید در مورد (تایم 10 دقیقه ) درج داده و مشکل دیتابیس رو به حداقل برسونید.
بله درسته. بنابراین، طبق گفته های شما و آقای نصیری، روش دوم باید کنار گذاشته بشه.
در روش اول، مشکل من بیشتر با ثبت و کنترل این تعداد رکورد (در مدت زمان کوتاه) هستش و در مورد حجم دیتابیس همانگونه که شما اشاره کردید این تعداد رکورد برای SQL (در صورتیکه صحیح مدیریت شود) عدد بسیار کوچکی است و مشکلی ایجاد نخواهد کرد.
در مورد تعداد پیشبینی رشد، نهایتا 1000 کالا و 1000 سایت خواهد بود و بیش از این نخواهد شد.
ولی ثبت همین تعداد رکورد (1 میلیون رکورد روزانه) هم باید در مدت زمان کوتاهی (مثلا 10 دقیقه) انجام بشه. در واقع، مشکل اصلی، مدت زمانی است که باید این داده ها دریافت و ثبت بشه. من دنبال روشی هستم (مثلا تغییر طراحی دیتابیس یا افزایش سرعت ثبت اطلاعات) که بشه این کار رو در زمان کوتاهی انجام داد. بررسی هایی که من انجام دادم دریافت اطلاعات از وب، زمان زیادی لازم ندارد و بیشتر بحث مدت زمانی است که داده ها در دیتابیس ثبت می شوند.
.بنابراین، اگر طراحی دیتابیس مشکلی نداشته باشه، باید روشی پیدا کنم که بتونم این داده ها رو در مدت زمان مورد نظر ثبت کنم
طبق مقالاتی که آقای نصیری به اون ها ارجاع دادند، با استفاده از روش هایی مثل MultiThreading میشه این کار رو انجام داد.
۱: راهکار بهینه، نیاز به دیتای بیشتری داره، چون مثلا سایز تیم تولید، دانش و امکانات نگهداری سیستم بعد از راه‌اندازی، زیرساخت و امکانات سخت‌افزاری و... می‌تونه پاسخ نهایی رو کلی تغییر بده.
۲: ۱۰۰۰ کالا از ۱۰۰ سایت، آیا دامنه تغییر این اعداد مثلا ۱۲۰۰ کالا از ۱۳۰ سایت خواهد بود؟ یا امکانش هست که در کوتاه/میان‌مدت تبدیل به ۱۰٬۰۰۰ کالا از ۵۰۰۰ سایت بشه؟ (پیشبینی رشد)
۳: ایندکس‌گذاری روی XML در SQL Server به خوبی پشتیبانی میشه، سایز XML در سریالایز/دیسریالایز شدن و طبیعتن در کارایی سیستم اثرگذار است
۴: برای محصولی مثل SQL Server نگهداری ۴۰ میلیون رکورد (۱ سال داده با اعدادی که فرمودید) عدد کوچکی است، «ولی» بسیار وابسته به اینه که زیرساخت خوب و مدیردیتابیس با دانشی داشته باشید وگرنه حتی ۴۰۰٬۰۰۰ رکورد هم می‌تونه مشکل ایجاد کنه
۵: این نوع سیستم‌ها عموما در مرحله جمع‌آوری به صورت OLTP طراحی می‌شن و برای سابقه به DW با ساختار Dimensional تبدیل و منتقل می‌شن. باز هم بستگی به تیم و شرایط تولید داره
۶: نکته بعدی اینکه مثلا به راحتی می‌تونید دیتا رو روی جدول پارتیشن‌بندی کنید و پارتیشن‌های قدیمی رو فشرده کنید
