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

[chaown]

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

[rezaonline.net]

اگه تعداد رکوردهاتون خیلی بالاست دیتابیسهای nosql پیشنهاد میشه .
اگر قصد راه اندازی سایت شبکه اجتماعی دارید postgresql پیشنهاد میشه .

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

[mbf5923]

البته من با دوستمون موافق نیستم چون mysql در حال حاضر در عرصه وب پیشتاز هستش اگه ساختار درستی در دیتابیس پیاده سازی کنید برای هر مقدار داده جوابگو و مناسبه

[mahmod2000]

بهترین راه چیه؟

آقا رضا شما میگی که دیتابیس رو Lock میکنید به چه صورتی انجام میشه؟

ممنون میشم توضیحی بدید در این مورد

[rezaonline.net]

البته من با دوستمون موافق نیستم چون mysql در حال حاضر در عرصه وب پیشتاز هستش اگه ساختار درستی در دیتابیس پیاده سازی کنید برای هر مقدار داده جوابگو و مناسبه


MySQL برای هر مقدار داده ای جوابگو نیست دوست عزیز .
توی دنیای کامپیوتر همیشه یه ماکزیمم وجود داره .
این لینک رو مشاهده کنید
https://dev.mysql.com/doc/refman/5.0/en/limits.html
و این لینک
https://dev.mysql.com/doc/refman/5.0/en/table-size-limit.html

بیشترین حجم هر فایل برای هر جدول روی سولاریس 16TB هست و روی لینوکس 4TB
اما این لینکو ببینید .
http://www.postgresql.org/about/
بیشترین حجم هر جدول رو تا 32TB تعیین کرده .

بیشتر از این نمیخوام در این مورد بحث کنم جستجو کنید به نتایج بهتر میرسید .
اما در کل حرف آخر اینکه MySQL جوابگوی نیاز برنامه هایی که ما مینویسیم هست اما اگر نگاه بلند مدتی داشته باشیم و دیتاهای حجیم باید یه خورده وسواس به خرج بدیم .


آقا رضا شما میگی که دیتابیس رو Lock میکنید به چه صورتی انجام میشه؟
برای اون کاری که بنده لازم داشتم لاک کردن تیبل جوابگو بود ، میتونید دسترسی نوشتن رو لاک کنید تا یک کاری انجام بدید
LOCK TABLES `invoice` WRITE
میتونید از transaction هم استفاده کنید.

[mbf5923]

بنده قصد جسارت ندارم ولی:
شما شبکه اجتماعی رو مثال زدین و فرمودید mysql جوابگو نیست بنده عرض کردم با اون صحبت شما موافق نیستم چون شبکه اجتماعی عظیم تر از فیسبوک نداریم و اون هم از mysql استفاده میکنه مشکلی هم نداره پس اینجا طراحی حرف اول رو میزنه.
البته فقط فیسبوک نیست فلیکر و توئیتر و ... هرچی سایت ابردیتا سراغ داریم دارن از mysql بهره میبرن
در مورد دیتا 16tb رو تصور بفرمایید و بعد سروری رو پیدا بکنید که این مقدار هارددیسک در اختیارمون بذاره بنده قول میدم اون مشکل mysqlرو هم برطرف کنم

[mohsen_31369]

بنده قصد جسارت ندارم ولی:
شما شبکه اجتماعی رو مثال زدین و فرمودید mysql جوابگو نیست بنده عرض کردم با اون صحبت شما موافق نیستم چون شبکه اجتماعی عظیم تر از فیسبوک نداریم و اون هم از mysql استفاده میکنه مشکلی هم نداره پس اینجا طراحی حرف اول رو میزنه.

فیسبوک از Apache Cassandra هم استفاده می کنه که noSql است.
برخی قسمت ها رو هم از mySql استفاده می کنه ( البته مطمئن نیستم)

[SlowCode]

این مطلب رو بخونید، قشنگ همه چی رو توضیح داده:
http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/
طبق این مطلب فیسبوک 30000 تا سرور داره! هم از mysql استفاده میکنه و هم nosql

این هم یه مصاحبه است که قابلیت های mysql رو میگه:
http://www.facebook.com/notes/facebook-engineering/mysql-and-database-engineering-mark-callaghan/10150599729938920

[مهرداد سیف زاده]

در مورد سایت‌های بزرگ مثل فیس‌بوک و یوتیوب و ... که حجم داده‌ها و دسترسی‌ها بسیرا بالاست از سرورها بصورت replication (http://dev.mysql.com/doc/refman/5.0/en/replication.html) و cluster (http://www.mysql.com/products/cluster/) استفاده میکنن. حالا حتی اگر از nosql هم استفاده کنن بازم این روش‌ها رو روی اون پیاده سازی میکنن و تمام اطلاعات بصورت متوازن در سرورهای بزرگ در سراسر جهان ذخیره میشن.

[eshpilen]

این مطلب رو بخونید، قشنگ همه چی رو توضیح داده:
http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/
طبق این مطلب فیسبوک 30000 تا سرور داره! هم از mysql استفاده میکنه و هم nosql

این هم یه مصاحبه است که قابلیت های mysql رو میگه:
http://www.facebook.com/notes/facebook-engineering/mysql-and-database-engineering-mark-callaghan/10150599729938920
لینک اول بسیار مطلب خوبی بود (دومی رو هنوز وقت نکردم بخونم).
اگر دقیق بخونید متوجه میشید که راه اندازی یک سایت در حد فیسبوک کاری نیست که بشه با برنامه نویسی عادی چندتا سایت معمولی مقایسش کرد. نیاز به منابع انسانی و مالی زیادی داره. اینا درحدی هستن که حتی لینوکس رو دستکاری و سفارشی کردن برای سرورها و کاربرد خودشون. بعد خیلی نرم افزارهای جدید رو حتی اختراع کردن یا توسعه دادن و بهینه کردن. اینکه بعضی تا حرفی میشه صحبت از فیسبوک میکنن انگار که فقط بحث برنامه نویسی اپلیکیشن عادی هست و دوتا بهینه سازی کد و دیتابیس عادی، درست نیست. خیلی بیش از این نیاز به دانش و کار در زمینه ها و لایه ها و سطوح مختلف داره. درواقع خیلی از فناوریها و برنامه های موجود، برای این سایتها به این گستردگی و این حجم ترافیک عظیم پاسخگو نیستن و باید با برنامه های اختصاصی جایگزین بشن یا تغییر و سفارشی سازی و بهینه سازی و غیره بشن. از سیستم عامل بگیر تا خود PHP و دیتابیس و غیره.
ضمنا فیسبوک فقط از PHP استفاده نمیکنه و از چندین زبان (سی++، جاوا، Erlang) در بخشهای مختلف استفاده میکنه و ضمنا فریمورکی هم طراحی و تولید کرده برای ارتباط راحتتر بین این زبانها.
مطلب دیگری که بنظرم ارزش توجه داشته باشه اینه که حتی فیسبوک با این همه منابع انسانی و مالی نمیتونه همه چیز رو از قبل بقدر کافی پیشبینی و طراحی کنه و خیلی مسائل در جریان کار و تجربه و روند گسترش پیش میان که باید تحلیل و حل بشن. مثلا نوشته که سیستم ذخیرهء تصاویر فیسبوک چند بار بطور کامل بازنویسی شده. بنده هم قبلا به این نکته اشاره کرده بودم که بیشتر سایتها و نرم افزارهای معروف به مرور زمان و بصورت تدریجی و تکاملی به جایی رسیدن که امروز رسیدن و نباید فکر کرده که باید و اصلا میشه همه چیز رو از همون روز اول برای هر شرایط و مقیاسی بخوبی طراحی و پیاده سازی کرد (بخصوص برای کسانی که برنامه نویسان خیلی برجسته و باتجربه ای هم نیستن!).
البته فیسبوک برای اینکه بتونه این تغییرات و واکنش ها رو هم بصورت سریع و بدون مشکلات جدی برای کاربران و برنامه نویسان و down شدن اعمال و تست و بررسی بکنه، بازهم سیستم و برنامه های خاص خودش رو طراحی کرده. این نشون میده که تیم فنی و برنامه نویسان فیسبوک واقعا چقدر کامل و قویه و تقریبا هیچ کاری نیست که از پسش برنیان. از سفارشی کردن هستهء سیستم عامل بگیر تا تغییر PHP و ایجاد برنامه ها و روشهای جدید برای مقیاس های خیلی بزرگ.

[eshpilen]

خلاصه آقا جان شما داری برنامه و سایت درست میکنی جوگیر نشو فکر نکن داری واسه فیسبوک درست میکنی :لبخند:
یه چیزی درحد فیسبوک اصلا بحث و مقولهء دیگری هست. نیاز به دانش و کارهایی داره خیلی فراتر از کاری که دوتا برنامه نویس وب عادی انجام میدن. فقط بحث یه PHP و بهینه سازی کد و دیتابیس و کوئری در اون سطح نیست. داستان خیلی از این حرفا گسترده تر و پیچیده تر و دشوارتره. قدم اولش بحث سیستمهای توزیع شده هم هست با صدها و چند هزار سرور.
بقول یارو میگن کار هرکس نیست خرمن کوفتن، گاو نر میخواهد و مرد کهن.
یعنی تعجب نکن اگر گفتن باید حتی اسمبلی هم بلد بود و استفاده کرد! تعجب نکن اگر لازم شد روی هستهء لینوکس هم کار کنن.
اینا نیاز دارن در تمام لایه ها از سخت افزار شروع کن و هستهء سیستم عامل و اسمبلی بگیر تا بیای برسی به PHP و HTML عادی درگیر بشن و روش کار کنن. نیروی انسانی متخصص در تمام این زمینه ها نیاز دارن که واقعا دانش و توان انجامش رو داشته باشن.
ببین چکار کردن مثلا کامپایلر نوشتن PHP رو تبدیل میکنه به کد سی++ اونم از نوع شدیدا بهینه شده. عمرا این کار از عهدهء برنامه نویسهای عادی برمیاد بنظرتون؟

[mbf5923]

باتشکر از دوست خوبم eshpilen
البته منظور بنده در این بود که هرسایتی رو بخواهید استارتش رو با همین PHP معمولی Mysql سفارشی نشده وlinux بهینه نشده میشه زد اونوقت اگه دیدید دارید به فیسبوک نزدیک میشید برید سراغ مواردی که دوستمون بهش اشاره کردن.

[chaown]

لینک اول بسیار مطلب خوبی بود (دومی رو هنوز وقت نکردم بخونم).
اگر دقیق بخونید متوجه میشید که راه اندازی یک سایت در حد فیسبوک کاری نیست که بشه با برنامه نویسی عادی چندتا سایت معمولی مقایسش کرد. نیاز به منابع انسانی و مالی زیادی داره. اینا درحدی هستن که حتی لینوکس رو دستکاری و سفارشی کردن برای سرورها و کاربرد خودشون. بعد خیلی نرم افزارهای جدید رو حتی اختراع کردن یا توسعه دادن و بهینه کردن. اینکه بعضی تا حرفی میشه صحبت از فیسبوک میکنن انگار که فقط بحث برنامه نویسی اپلیکیشن عادی هست و دوتا بهینه سازی کد و دیتابیس عادی، درست نیست. خیلی بیش از این نیاز به دانش و کار در زمینه ها و لایه ها و سطوح مختلف داره. درواقع خیلی از فناوریها و برنامه های موجود، برای این سایتها به این گستردگی و این حجم ترافیک عظیم پاسخگو نیستن و باید با برنامه های اختصاصی جایگزین بشن یا تغییر و سفارشی سازی و بهینه سازی و غیره بشن. از سیستم عامل بگیر تا خود PHP و دیتابیس و غیره.
ضمنا فیسبوک فقط از PHP استفاده نمیکنه و از چندین زبان (سی++، جاوا، Erlang) در بخشهای مختلف استفاده میکنه و ضمنا فریمورکی هم طراحی و تولید کرده برای ارتباط راحتتر بین این زبانها.
مطلب دیگری که بنظرم ارزش توجه داشته باشه اینه که حتی فیسبوک با این همه منابع انسانی و مالی نمیتونه همه چیز رو از قبل بقدر کافی پیشبینی و طراحی کنه و خیلی مسائل در جریان کار و تجربه و روند گسترش پیش میان که باید تحلیل و حل بشن. مثلا نوشته که سیستم ذخیرهء تصاویر فیسبوک چند بار بطور کامل بازنویسی شده. بنده هم قبلا به این نکته اشاره کرده بودم که بیشتر سایتها و نرم افزارهای معروف به مرور زمان و بصورت تدریجی و تکاملی به جایی رسیدن که امروز رسیدن و نباید فکر کرده که باید و اصلا میشه همه چیز رو از همون روز اول برای هر شرایط و مقیاسی بخوبی طراحی و پیاده سازی کرد (بخصوص برای کسانی که برنامه نویسان خیلی برجسته و باتجربه ای هم نیستن!).
البته فیسبوک برای اینکه بتونه این تغییرات و واکنش ها رو هم بصورت سریع و بدون مشکلات جدی برای کاربران و برنامه نویسان و down شدن اعمال و تست و بررسی بکنه، بازهم سیستم و برنامه های خاص خودش رو طراحی کرده. این نشون میده که تیم فنی و برنامه نویسان فیسبوک واقعا چقدر کامل و قویه و تقریبا هیچ کاری نیست که از پسش برنیان. از سفارشی کردن هستهء سیستم عامل بگیر تا تغییر PHP و ایجاد برنامه ها و روشهای جدید برای مقیاس های خیلی بزرگ.

برادر عزیز اینقدر زحمت کشیدی نوشتی ، ولی کسی قصد درست کردن این سیستمها رو نداره ، حداقل شخصا فکرشم نمیکنم :لبخند: ، فقط می خواستم بدونم در مواقعی که درخواست همزمان زیاد میشه چکار باید کرد مثلا ( با اجازه شما ) سایتی مثه سنجش.


میتونید از transaction هم استفاده کنید.
اگه میشه در مورد transaction یکم توضیح بدین و اگه میشه یه مثال بیارین. چیزه مهم و پر کاربردی هست. ولی من باد نیستم :لبخند:

[eshpilen]

اگه میشه در مورد transaction یکم توضیح بدین و اگه میشه یه مثال بیارین. چیزه مهم و پر کاربردی هست. ولی من باد نیستم :لبخند:
البته بارها وقتی صحبت از تداخل درخواست ها و استفاده از قفل برای جلوگیری از اون شده، افراد اسم ترنزکشن رو هم به میان آوردن و گفتن که میشه بجای قفل ازش استفاده کرد.
اما بنده به این قضیه مشکوک بودم و بنابراین روش تحقیق و تست کردم و متوجه شدم که حتی ترنزکشن هم بصورت عادی جلوی تداخل کوئری های چند درخواست جداگانه رو نمیگیره! اما ما میتونیم این کار رو با اظهار صریح و قرار دادن دستورات لازم در کوئری های یک ترنزکشن انجام بدیم. بهرحال در پشت صحنه این همون مکانیزم های قفل است که کار رو به انجام میرسونن، منتها این بار از نوع و در قالب انجین و سیستم ترنزکشن دار (که احتمالا بهینه تر باشه البته).
این مقاله درمورد تحقیق و تست های بنده: http://www.hamidreza-mz.tk/?p=940

البته کاربرد ترنزکشن فقط این قضیهء قفل و جلوگیری از تداخل درخواستهای همزمان نیست و کاربرد اصلی و هدف اون درواقع اطمینان از اجرای کامل و بدون مشکل چند کوئری وابسته است. کوئری هایی که در یک ترنزکشن قرار گرفته باشن یا همه با موفقیت اجرا میشن و یا همه اجرا نمیشن. یعنی اینطور نیست که مثلا چندتا کوئری اجرا بشن و چندتای دیگش با شکست مواجه بشن و به این شکل سازگاری داده های دیتابیس و منطق برنامه دچار مشکل بشه.

[mbf5923]

البته ناگفته نماند که اصلاح روش های برنامه نویسی هم در این زمینه میتونه موثر باشه.مثلا استفاده بجا از trigger ها و storedprosedur ها و event ها میتونه تعداد درخواستهای برنامه از dbms رو پایین بیاره.