mysql و دیتا حجیم

ببینید دوست عزیز به نظر من اصلا اشتباه نیست که بخوای از لاراول توی دیتاهای حجیم استفاده کنی، به هر حال کلی وب سایت هست که اتفاقا دیتاهای زیادی دارند مثل op.gg یا خود وب سایت laracasts که از لاراول استفاده می کنند و هیچ مشکلی ندارند.
شاید توی زمینه دیتابیس کمی (فقط کمی) از زبون های دیگه کند تر باشه اما اصلا اینطور نیست که بخواد کارتو خراب بکنه، چون لاراول چیز تازه ای نیست و قطعا اینجور مشکلات رو خیلی وقت پیش پیش بینی کردند.
شما یکم وقت بذار و برو درباره بهینه کردن کوئری ها توی لاراول بخون، مقاله های زیادی هست مثل این :
مقاله مورد نظر

یکم انگلیسی راجع بهش سرچ کنی (مثلا laravel optimize query) و مقاله های مختلف و راه کار های مختلف رو بخونی متوجه میشی که مشکلی برات پیش نمیاد.

سوالتون یک سوال فوق تخصصی محسوب میشه به نظرم و حتما لازمه با افرادی مشورت کنید که تجربه پیاده سازی اپلیکیشن های largeScale رو داشتند و به این چالش ها خوردن. اما در کل دوست دارم که نظرات خودم رو براتون بیان کنم :

1 - جواب سوال سومتون مربوط به مموری لیمیت اسکریپت PHP هستش که شما در حال اجرای اون هستید و چون به کد php که اجرا میکنید . در حالت عادی مموری مجازبرای اجرای هر اسکریپت عادی php مقدار 8 مگابایت هستش و این خطا به این دلیل است . در حالی که شما در حالت عادی یکی یکی به دیتابیستون اطلاعات وارد می کنید.
2 - جواب سوال دومتون ، لازم هست که اسکریپت php لیمیت داشته باشه . چون روی سرور شما به صورت همزمان هر بار چندین ریکوست در حال اجرا هست و اگر یکی از این اسکریپت ها مموری زیادی از سرور شما بگیره ، شاهد هنگ سرور خواهید بود!
3 - mysql با دیتای حجیم مشکلی نداره ! بنده شاهد این مورد هستم که دیتابیس یه سری از شرکت های حال حاضر که دارن کار میکنن و روی mysql هستش بیشتر از 30 گیگابایت هم رسیده و هیچ مشکلی نداره .
در نظر داشته باشید که :
اولا : در صورتی که تعداد ریکوست به اپلیکیشن شما زیاد بشه عادی هست که سرعت پردازش و پرفورمنس اپلیکیشن شما پایین بیاد
دوما : مبحث مربوط به دیتا حجیم در mysql بسیار ارتباط به کار و دستوری هست که شما در حال اجرای اون در mysql هستید . مثلا وقتی شما در یک تیبل با حجم 1 GB هم دستور insert رو بدید تفاوت سرعت آنچنان با حالتی که تیبل خالی باشد ندارید ! اما در صورتی که بخواهید قسمتی از این تیبل را retrieve کنید با مشکل کندی سرعت مواجه خواهید شد.
سوما : معمولا شما به وسیله ی دیزاین صحیح دیتا بیس خود باید حجم دیتابیسی که به صورت مستقیم در ارتباط با یوزر های شما است ، حجم تیبل هایی که بیشتر توسط یوزر استفاده می شود را پایین بیاورید. مثلا :‌شما صفحه ی اول سایت فروشگاهی را در نظر بگیرید که چند محصول را به مشتری نشان می دهد. باید تیبل محصولاتتون رو طوری دیزاین کنید که حجم کمی داشته باشد + اینکه تعداد محصول انقدر زیادی داخل دیتابیس یک فروشگاه نیست معمولا ! در حالی که در پنل ادمین این فروشگاه ممکن است لاگ تمام درخواست های یک یوزر رو داشته باشید که حجم بسیار بزرگی دارد و در حالتی که این دیتا رو در صفحه ای میگیرید کندی سرعت رو شاید ببینید اما تا حدی می توان گفت که مهم نیست ( زیرا با یوزر های مراجعه کننده سایت شما در ارتباط نیست بلکه با مدیران و ادمین ها در ارتباط است )
4 - مورد چهارم اینکه :‌قرار نیست شما اپلیکیشنی رو طراحی کنید که روز اول برای یک قابلیت largeScale پاسخگو باشد! بسیاری از شرکت ها مثلا دیجیکالا تا یکی دو سال پیش هم از PHP استفاده می کرد و پاسخگو هم بود ) . بسیاری از شرکت ها ابتدا سامانه های خودشون رو با هزینه کم طراحی می کنند و بعدا که نیاز باشه به این موارد بیشتر توجه می شود .

خیلی ممنونم که وقت گذاشتین و سوال من را جواب دادین
لازمه که بگم از موارد زیر به شدت پیروی می کنم و تا جایی که مشتری پافشاری و اسرار نکنه اون ها را رها نمی کنم اگر موردی هست که اشتباه می کنم تذکر بدید یا اگه کم هست پیشنهاد کنید
1 - همه جداولی که میسازم ایندکس شده اند (بعضی از کوئری های پر تکرارم هم ایندکس های ترتیبی می کنم ولی سعی میکنم در ایندکس کردن تعادل را رعایت کنم و به هیچ وجه زیاده روی نکنم) و تا اونجایی که بشه در کوئری هام از ایندکس های که گذاشتم استفاده می کنم
2- تا اونجایی که ممکنه از ذخیره کردن string و text پرهیز می کنم و اکثر جداولم با اعداد و id ها سرو کار دارند
3 - تا اونجایی که بشه سایز column ها را مناسب با دیتا ی ورودی و حالت های حدی در نظر می گیرم و سایز اضافی نمی دم(البته دیتای ورودی را در insert حتما چک می کنم از حالت حدی رد نشه )
4-تمام سعی ام را می کنم که اگر قرار هست دیتای جداول مرتبط با موضوع اصلی صفحه را نشان بدهم به جای اینکه کلی اطلاعات ریز و درشت بریزم توی صفحه و باعث کوئری پیچیده بشم دسترسی به اطلاعات را خورد کنم . مثلا یک فیلد "اطلاعات بیشتر" به کاربر نمایش میدهم که با زدن اون بره داخل همون رکورد و سایر اطلاعات و را بگیره
5 - هر جایی که قرار باشه لیستی از اطلاعات پر تعداد را نمایش بدم (اگر لیست طبیعت حجیم شدن در طول زمان را داشته باشه) بدون استثنا از pagination با حجم زیر صدتا استفاد ه می کنم تا کاربر بتونه بین صفحات دیتای ایجاد شده جا به جا بشه
6 -سعی می کنم اگر جدول خاصی را در یک صفحه سرچ زدم . مختصری از اطلاعات به دست امده را به هر صفحه ی لینک با این صفحه که قراره همین سرچ را تکرار کنه بفرستم و اونجا دیگه این سرچ و نزنم (البته با حفظ policy)
7- اگر شرایط ایمن فراهم باشه به جایی اینکه انالیز داده های جزئی را سمت سرور انجام بدم یا نحوه ی نمایش اونها را سمت سرور مشخص کنم اطلاعات کم خطر را به صورت خام سمت کاربر بفرستم و کلیه آنالیز ها و چیدمان ها و نمایش ها را سمت کاربر کنترل می کنم ( مثلا به جای اینکه سمت سرور بگم کدوم مطالب چه رنگی باشن و چه استایلی داشته باشن. سمت کاربر هندل می کنم )
8 - بعضی وقت ها از جداولی که چکیده جداول حجیم و نگه داری میکنن استفاده می کنم(مثلا وقتی یه رکورد به جدول بدهی های یک نفر اضافه میشه ممکنه صدتا رکورد بدهی دیگه هم برای همین کاربر باشه اما من یک جدول دارم که این کاربرم فقط یک رکورد داره و مجموع بدهی هاش در یک فیلد و مجموع طلبهاش هم در یک فیلد به صورت خلاصه و مفید به صورت transaction ذخیره میشه )
اگر توصیه مفیدی دارید که می تونه کارم را سریع تر کنه یا موضوع اشتباهی را دارم دنبالم می کنم خیلی خوشحال میشم نظرتون را بشنوم

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

به گفته کاربر حمید مربوط به ۶ سال پیش :

محدودیت حجم کل پایگاه داده در SQL Server به ۵۱۲ پتا بایت است بجز ورژن Express.

محدودیت حجم یک جدول در SQL Server تا ۱۸۰ هزار ترابایت است بجز ورژن Express.

روشهای متعددی برای بالابردن سرعت بازدهی وجود دارد. یک روش برای پایگاه داده های بسیار حجیم (بیش از ۳۰۰ ترابایت) ScaleOut است.

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

با توجه به محدودیت های بسیار زیاد In-Memory Tables در SQL Server 2014 این روش پیشنهاد نمیشود مگر اینکه از SQL Server 2016 استفاده شود.

پاسخ‌های تفصلی تر رو دوستان اشاره کردند. فقط من باب تاکید اینکه به نظرم در این مقیاسی که می‌فرمایید هیچ محدودیت و مشکلی از سمت MySQL و Laravel نخواهید داشت.
و اگر می‌بینید مشکلاتی از قبیل محدودیت RAM و ... می‌خورید علتش بر میگرده به نحوه استفاده ناصحیح خودمون.

مثلا اصلا کار اصولی و منطقی نیست که حجم زیاد اطلاعات رو به صورت یکجا بخواهیم insert کنیم و در عمل هم هیچ وقت چنین چیزی رخ نخواهد داد. بلکه معمولا کوئری ها بصورت تکی اجرا میشن و این قضیه خیلی فرقش هست با اینکه شما بیاید ۵ میلیون رکورد رو خواسته باشید اول تو مموری لود کنید و بعد یکجا روی دیتابیس insert کنید.
راه حل های خیلی زیاد و رایجی هم برای اینجور داستان ها وجود داره. مثلا از متد Chunk لاراول می‌تونید استفاده کنید که میاد داده هاتون رو مثلا در بسته های ۱۰۰۰ تایی تقسیم می‌کنه و هزار تا هزار تا در مموری لود می کنه و داخل دیتبایس میریزه و مموری رو آزاد میکنه و ادامه میده تا تموم بشه.