مشکل حجم سنگین بانک [بایگانی]

ehsane

چهارشنبه 13 مهر 1384, 15:28 عصر

با سلام
در یک برنامه تحت شبکه کاربران هر روز تعداد 50 رکورد به به بانکهای موجود اضافه می کنند این رکوردها شامل یک فیلد تصویر نیز هست که باعث کند شدن سیستم و بالا رفتن حجم بانک شده است ( 1200 رکورد در حدود یک گیگا بایت ) بنظر شما مشکل در کجاست و آیا راه حلی برای این موضوع وجود دارد یا خیر. ( دیتا بیس Sql Server)

Touska

چهارشنبه 13 مهر 1384, 16:32 عصر

خوب شما فیلد blob تون را Comperess می منید یا نه.

ehsane

پنج شنبه 14 مهر 1384, 08:01 صبح

نه ، دوست عزیز اگه ممکنه یک کم راهنمایی کنی.

Touska

پنج شنبه 14 مهر 1384, 10:43 صبح

شما باید عکسی رو که میخواهید در Database ذخیره کنید باید قبل از ذخیره کردن با استفاده از

ابزار stream و buffer یا کامپوننتهای آماده فشردخ کنید.

دنیای دلفی

پنج شنبه 14 مهر 1384, 11:13 صبح

به جای ذخیره تصویر آدرس آن را ذخیره نمائید

ehsane

پنج شنبه 14 مهر 1384, 12:43 عصر

vcldeveloper

جمعه 15 مهر 1384, 02:36 صبح

دوست عزیز ایده ذخیره آدرس خوب است ولی زمانی که شما میخواهید برنامه را در کلاینت ها نصب کنید باید مدیر شبکه برای هر کلاینت یک یوزر تعریف و دسترسی آنرا به محل ذخیره تصاویر بر روی شبکه مشخص کند که کاری مشکل و وقت گیر است.
می تونید بجای اینکار برنامه رو بصورت 3-لایه بنویسید. اطلاعات از بانک (یا دیسک) توسط App Server خوانده میشه و کلاینت ها برای دسترسی به اون اطلاعات فقط کافیه که به App Server دسترسی داشته باشند.
برای اطلاعات بیشتر به مبحث DataSnap در راهنمای دلفی یا اینترنت مراجعه کنید.

Naficy

جمعه 15 مهر 1384, 13:39 عصر

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

hr110

شنبه 16 مهر 1384, 07:23 صبح

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

ehsane

شنبه 16 مهر 1384, 07:34 صبح

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

Naficy

سه شنبه 19 مهر 1384, 13:09 عصر

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

Kamyar.Kimiyabeigi

سه شنبه 19 مهر 1384, 16:47 عصر

من فکر میکنم که 1200 تا رکورد و 1200 تا عکس یه مقداری غیر طبیعی هست.
به غیر از راه حلهایی که دوستان داشتند.آیا شما این امکان رو دارید که برای تصاویری که
کاربران ذخیره میکنند محدودیت بگذارید؟؟؟

vcldeveloper

چهارشنبه 20 مهر 1384, 01:40 صبح

نوشتن فایل سرور یا پیشنهاد آقای کشاورز به تنهایی هیچ کمکی نه به سرعت و نه به حجم نمی کنه.
پیشنهاد بنده و جناب آقای ربیعی در جهت رفع این مشکل بود:

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

Naficy

چهارشنبه 20 مهر 1384, 11:37 صبح

صحیح. اما توجه دارید که نوشتن برنامه با DataSnap کمکی به هیچی نمی کنه. مگر اینکه فایل سروره رو "هم" بنویسین.
نوشتن فایل سرور و ذخیره آدرس هم تنها باعث می شه اطلاعات رو در Blob ذخیره نکنیم. فکر می کنم خواندن فیلد Blob برای SqlServer نباید چندان کار زمانبری باشه. یعنی اصل کند بودن برنامه مربوط به شبکه، ترافیک همزمان چند کاربر و... است، نه مربوط به سرعت بازخوانی فیلد Blob روی سرور. یعنی ذخیره آدرس (و به تبع آن نوشتن فایل سرور) کمک چندانی به سرعت نمی کنه.

برای همین می گم فقط دو راه منطقی برای حل مشکل وجود داره. کمپرس و Cache.

ehsane

چهارشنبه 20 مهر 1384, 13:07 عصر

دوست عزیز
1- یعنی بنظر شما اگر در یک لحظه 10 کاربر هر کدام 20 تصویر را درخواست کنند در روش ذخیره سازی اطلاعات در فیلد Blob هیچ مشکلی پیدا نمیشه و سرعت کم نمی شه.

2- فرض دوم اینست که فکر کنیم که بانک شامل متن و تصاویر صفحات یک کتاب 1000 صفحه ای است و اگر کاربر همه تصاویر را درخواست کند آن موقع چه مشکلی ممکن است پیش بیاید ( مورد دوم را تجربه کرده ام - ه کاربر هر کدام 1000 رکورد را درخواست کرده ند و در عمل شبکه بسیار کند شد.)

Naficy

چهارشنبه 20 مهر 1384, 16:20 عصر

1 - نه نمی شه.
اگر منظورتون از "درخواست"، خواندن اطلاعات است که مسلما مشکلی پیش نمی یاد.
اگر بر فرض محال منظورتان از "درخواست"، ذخیره اطلاعات هم باشد؛ بازهم چه تصاویر در فیلد ذخیره بشن چه در فایلهای جدا جدا، مساله به یک اندازه بغرنج خواهد بود.
2 - مسلمه که سرعت شبکه پایین می یاد. سرعت شبکه به حجم اطلاعات در حال جابجایی بستگی داره. از طرفی همونطور که قبلا هم گفتم در این مورد هم فرقی نمی کنه تصاویر درون دیتابیس ذخیره بشن یا در فایلهای جداگانه.

************************************
به نظرم منظور منو متوجه نشدین.
من می خوام مقایسه کنم کدوم بهتره:
1- تصاویر درون دیتابیس ذخیره بشن. (به کمک فیلد image یا blob)
2- تصاویر در فایلهای جداگانه ذخیره شده و آدرس آن فایلها درون دیتابیس ذخیره شود.
و هدفم هم اینه که بگم راه حلی که پیشنهاد کردن (ذخیره آدرس) هیچ مشکلی رو حل نمی کنه. (و به تبعش راه حلهایی مثل فایل سرور و... هم سودی ندارن)

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

vcldeveloper

پنج شنبه 21 مهر 1384, 01:48 صبح

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

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

vcldeveloper

پنج شنبه 21 مهر 1384, 03:07 صبح

من می خوام مقایسه کنم کدوم بهتره:
1- تصاویر درون دیتابیس ذخیره بشن. (به کمک فیلد image یا blob)
2- تصاویر در فایلهای جداگانه ذخیره شده و آدرس آن فایلها درون دیتابیس ذخیره شود.
ذخیره تصاویر بصورت فایل میتونه به میزان کمی باعث افزایش کارایی بشه، چون :
1- در صورت استفاده از فایل، می توان اطلاعات را بر روی چند هارد پخش کرد و به این ترتیب تا حدودی سرعت read\write اطلاعات در سرور را بالا برد (البته ویژگی FileGroup در SQL Server هم تقریبا سعی در پیاده سازی همین مورد دارد).
2- بیشتر دادهایی که در بانک های اطلاعاتی ذخیره میشند، بصورت Text هستند؛ در نتیجه، اکثر RDBMS ها بیشتر برای کار با Text بهینه سازی میشند.

اما استفاده از فایل یکسری ضعف هایی هم داره:
1- در صورت حذف یک فایل، لینک مربوط به آن در دیتابیس نامعتبر میشه.
2- باید با دو سیستم امنیتی کنار بیاید (سیستم امنیتی دیتابیس و سیستم امنیتی سیستم عامل)
3- باید از دو شیوه متفاوت برای دسترسی به دادها استفاده کنید (یکی برای داده های موجود در دیتابیس و دیگری برای فایل ها)
4- انجام عملیاتی باید بر روی کل داده ها اعمال شوند (مثل پشتیبانی گیری) به کار بیشتر نیاز خواهد داشت.
------------------------------------

با افزایش کارایی سخت افزاری سرور و بهینه سازی ساختار بانک اطلاعاتی، می تونید تا حدودی کارایی برنامه را افزایش دهید، اما مسلما اصلی ترین گلوگاه سرعت در برنامه ایی که داده هایی با حجم بالا را در شبکه رد و بدل می کنه، پهنای باند موجود در شبکه هست. برای بهینه سازی این مورد هم یا باید ساختار شبکه و تجهیزات به کار رفته در آن را اصلاح کنید (که معمولا همچین کاری به راحتی ممکن نیست) یا باید در برنامه خودتون در سمت کلاینت از مکانیزم هایی برای فشرده سازی یا cache کردن داده ها استفاده کنید.
برای فشرده سازی داده ها می تونید از Zlib یا کامپوننت هایی که در این زمینه وجود دارند استفاده کنید و یا خودتون روتین های فشرده سازی رو بنویسید.
cache کردن داده ها کار پیچیده تری هست. یک راه حل ساده که الان به نظرم میرسه، اینه که:
1- به جداولی که شامل فیلد باینری هستند، فیلدی هم برای ذخیره تاریخ و زمان آخرین تغییر، اضافه کنید.
2- در سمت کلاینت یک Memory Table ایجاد کنید (مثلا با استفاده از TClientDataSet). ساختار این table را بگونه ایی تعریف کنید که بتوان در آن اطلاعاتی مثل ID رکورد (هر شناسه ایی که بتوان با آن رکورد انتخاب شده را تشخیص داد)، تاریخ و زمان آخرین ویرایش و آدرس فایل را ذخیره کرد.
3- هر زمان که کاربر درخواست دریافت یک تصویر را می کند:
الف- ID رکورد مورد نظر را در Memory Table ایی که ایجاد کردید، جستجو کنید.
ب- اگر ID مربوطه در جدول موجود نبود:
a- عکس درخواست شده و فیلد مربوط به زمان آخرین ویرایش رکورد را از سرور درخواست کنید.
b- عکس را از حالت فشرده خارج کرده و روب هارد سیستم کلاینت ذخیره کنید.
c- شناسه رکورد، محل ذخیره فایل و زمان آخرین ویرایش رکورد را در جدولی که ایجاد کردید، ثبت کنید.

ج- اگه ID در جدول موجود بود، فقط زمان آخرین ویرایش رکورد مورد نظر را از سرور دریافت کنید و زمان آن را با زمان موجود در Memory Table مقایسه کنید، اگه زمان ها متفاوت بودند، رکورد مربوطه در Memory Table را حذف کنید و مراحل قسمت ب را انجام دهید. اگر زمانها یکسان بودند، عکس را از روی هارد سیستم کلاینت لود کنید.
4- در پایان، مسیر فایلهای cache شده را از Memory Table بخونید و آنها را پاک کنید.

ehsane

پنج شنبه 21 مهر 1384, 07:38 صبح

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

1- استفاده از ذخیره آدرس در بانک رفع کننده مشکل بصورت مقطعی است و میتواند در حالتی که تعداد کلاینت های موجود کم باشند مورد استفاده قرار گیرد و خوب هم جواب میدهد و دارای سرعت دسترسی خوبی نیز هست ولی همچنان مشکل نصب برنامه و تنظیمات دستی در کلاینت ها موجود است و اگر تعداد آنها بیشتر شود مشکل نصب و قطع و وصل شدن ارتباط و... وجود دارد که باید یا با آن کنار آمد یا آنرا به کناری گذاشت.

2- روش ذخیره تصاویر بصورت باینری در بانک را نیز تجربه کردم ( البته پیشنهاد شما جالبتر بود ) من در هر دفعه کل تصاویر را بازخوانی می کردم که این مشکل پایین رفتن سرعت شبکه را به همراه داشت.

3- آخرین روشی که مورد استفاده قرار دادم و الان با حدود 2000 تصویر در حال کار کردن بر روی شبکه است این بود که بانکی جدا جهت آدرسی دهی به فیلدهای مورد نظر ( متن ) ایجاد و در صورت درخواست کاربر ابتدا از آن بانک اطلاعات لازم را اخذ سپس بصورت مجازی در جلوی دید کاربر یک دکمه ( نمایش تصویر ) قرار دادم حالا هر وقت کاربر نمایش تصویر را کلیک می کند کد مورد نظر اخذ و در sql یک استور پروسیجر اجرا و نتیجه آن که حاوی فقط یک تصویر خواهد بود به برنامه باز می گردد و کاربر در هر لحظه می تواند یک تصویر را مشاهد و یا به تعبیری کتاب را ورق بزند. ( البته کل تصاویر را با کد مرتبط با متن را در یک table دیگر ذخیره کرده ام و تصاویر از آنجا خوانده میشوند)

------

Naficy

جمعه 22 مهر 1384, 05:01 صبح

بنده راه حل استفاده از DataSnap یا فایل سرور رو برای حل مشکل ترافیک شبکه مطرح نکردمبله. من هم چیزی غیر از این نگفتم. گفتم راه حل ذخیره آدرس بی فایده است. (که البته شما آنرا ارائه ندادید) و به تبع آن راه حلهایی که جهت بهبود آن ارایه شده (مثل راه حل شما) برای این سوال بی فایده خواهند بود.

-----------------------------------------------
از مقایسه خوبی که بین دو روش انجام دادید، متشکر. دلایل اصلی مخالفتم (دوگانه شدن محیط ذخیره اطلاعات برنامه) را هم بروشنی بیان کردید.
خب، شما یک دفعه جلوتر رفتید و پیاده سازی راه حل مرا هم بیان کردید. چیز دیگری برای گفتن باقی نمانده. (من قصد نداشتم پیاده سازی را تشریح کنم، تا زمانی که مستقیما مورد سوال قرار بگیره)
-----------------------------------------------
در ادامه صحبت دوستمان ehsane هم باید بگم؛ به نظر من بهترین و منطقی ترین روش قابل انجام، همین کاری بوده که انجام دادین. اصولا باید طراحی برنامه طوری باشه که کارهای پر حجم و زمانبر تا حد امکان انجام نشوند مگر با درخواست کاربر. خیلی تنگ نظری است که برنامه باید حتما فلان عمل سنگین را انجام دهد.
مطمئن باشید که راه حل بهتری نمی یابید. راه حلهایی که اینجا بیان شدند، تنها با فرض این بودند که برنامه شما مجبور به انجام چنین عملیاتی است. و در نهایت هم؛ این روشها فقط در شرایط محدودی مفید هستند.

b_mohammadpoor

شنبه 23 مهر 1384, 07:45 صبح

دوست عزیز علاوه بر تکنولوژی ذخیره سازی عکس , نوع سرور نیز در سرعت خیلی مهم است .
محل کار من 40000 پرونده سنگین در بانک ذخیره است که بیش از نیمی از اونا عکس دارن .
با این وضع اگر سرور یک کامپیوتر معمولی با سخت افزار و سرعت بالا هم باشه اصلا برنامه اجرا نمیشه چه برسه به اینکه سرعت پایین باشه ولی با کامپیوتر های تیپ سرور برنامه با 20 کاربر همزمان به خوبی داره کار میکنه .

hr110

شنبه 23 مهر 1384, 08:03 صبح

بهترین و منطقی ترین
بهترین و منطقی ترین باید در یک پروژه تعریف و تفسیر شود.
1- نرم افزاری که بیش از 450 هزار رکورد با حجم 30 گیگابایت با فایلهای جانبی ایی در حدود 600 گیگا بایت را باید از چه روشی استفاده نماییم، به نظر شما عقلانی است که این حجم اطلاعات در اسکیوال ذخیره شوند !؟(دلفی)
2- نرم افزار کتابخانه ایی برای ذخیره تصاویر اعضای کتابخانه با حدود 2000 کاربر ، به نظر شما منطقی است از فایل سرور استفاده شود!؟(دلفی و جاوا)
3- نرم افزاری با بیش از 2 میلیون رکورد 10 گیگا بایت و فایلهای ضمیمه ایی در حدود 150 سی دی برای استفاده در یک شبکه با بیش از 120 کاربر را باید چگونه پیاده سازی کرد؟؟؟ (جاوا)

این سه پروژه بخشی از پروژه هایی است که در حال حاضر بروی انها کار میکنم و مراحل آخر را طی میکنند، من برای هر یک از پروژه ها از یک روش استفاده کرده ام و هر سه به خوبی کار میکنند و کارفرما بسیار راضی است.
بنده حقیر توصیه میکنم در علم رایانه نباید زیاد مطلق صحبت کرد ;)

--------------
در مورد مزایا و معایب فایل سرور استاد کشاورز مطالب ارزنده ایی فرمودند و جسارتاً من چند مورد دیگر به مزایای استفاده از آن اضافه میکنم :
1- سرعت پشتیبانگیری افزایش خواهد یافت.
2- حجم فایلهای پشتیبان کاهش خواهد یافت، شما نیازی ندارید هر روز از تمام فایلهایتان پشتیبان بگیرید ولی پشتیبانگیری از اطلاعات ذخیره شده در اسکیوال به کاربران توصیه میشود.
3- به سادگی میتوانید نرم افزار خود را توزیع شده بنویسید و فایل سرور را بروی یک سرور دیگر منتقل نمایید. توزیع نمودن نرم افزارتان باعث خواهد شد برای هر یکی از مقاصد(سرویسها) سخت افزار متناسب با آنرا را ایجاد نمایید.
4- مزیت دیگر توزیع شدگی میتواند به شما امکان بدهد بروی شبکه خود چند فایل سرور نیز داشته باشید. به عنوان مثال اگر نرم افزار شما بروی چند شبکه محلی مورد استفاده قرار بگیرد میتوانید فایل سرورهای هر شبکه را جداگانه داشته باشید.
5- مزیت استفاده از چند فایل سرور میتواند به شما امکان بدهد که یک فایل را از چند فایل سرور لود کنید. مشابه عملی که در نرم افزارهای e-monky یا warez و .. انجام میشود.
البته این مسئله میتواند برای پروژه های بزرگ با تعداد کاربران زیاد و شبکه های محلی مختلف مورد استفاده قرار بگیرد و در پروژههای کوچک زیاد کاربرد نخواهد داشت و شاید همان روش استفاده از فیلد blob منطقی باشد.

موفق باشید

hr110

شنبه 23 مهر 1384, 08:06 صبح

دوست عزیز علاوه بر تکنولوژی ذخیره سازی عکس , نوع سرور نیز در سرعت خیلی مهم است .
محل کار من 40000 پرونده .....

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

Naficy

شنبه 23 مهر 1384, 13:17 عصر

بهترین و منطقی ترین باید در یک پروژه تعریف و تفسیر شود.
1- نرم افزاری که بیش از 450 هزار رکورد با حجم 30 گیگابایت با فایلهای جانبی ایی در حدود 600 گیگا بایت را باید از چه روشی استفاده نماییم، به نظر شما عقلانی است که این حجم اطلاعات در اسکیوال ذخیره شوند !؟(دلفی)
2- نرم افزار کتابخانه ایی برای ذخیره تصاویر اعضای کتابخانه با حدود 2000 کاربر ، به نظر شما منطقی است از فایل سرور استفاده شود!؟(دلفی و جاوا)
3- نرم افزاری با بیش از 2 میلیون رکورد 10 گیگا بایت و فایلهای ضمیمه ایی در حدود 150 سی دی برای استفاده در یک شبکه با بیش از 120 کاربر را باید چگونه پیاده سازی کرد؟؟؟ (جاوا)

این سه پروژه بخشی از پروژه هایی است که در حال حاضر بروی انها کار میکنم و مراحل آخر را طی میکنند، من برای هر یک از پروژه ها از یک روش استفاده کرده ام و هر سه به خوبی کار میکنند و کارفرما بسیار راضی است.
بنده حقیر توصیه میکنم در علم رایانه نباید زیاد مطلق صحبت کرد ;)
خسته نباشید. اینهمه پروژه را که نوشتید، خوب راه حلتان را هم می نوشتید بلکه یه فایده ای داشته باشه. (منم یه پروژه از ناسا و یکی از CIA گرفتم،..در آخر کار خیلی راضی بودند!!! :چشمک: )

لطف کنید وقتی نقل قول می گذارید کل جمله را بنویسید. یعنی فقط همان یک عبارت را دیدید؟

به نظر من بهترین و منطقی ترین روش قابل انجام، همین کاری بوده که انجام دادین. اصولا باید طراحی برنامه طوری باشه که کارهای پر حجم و زمانبر تا حد امکان انجام نشوند مگر با درخواست کاربر.
توی جمله بالا منظور من از "اصولا" معنای دقیقیش بوده: "مطابق اصول".

اصلا اتفاقا می خواهم مطلق صحبت کنم .
«مثال: هر آدم عاقلی می دونه که تا وقتی یه شبکه ۱۰mbs جواب می ده، نیازی به خرید تجهیزات سنگین و گران برای شبکه نیست. (البته مسلمه که همون آدم عاقل می دونه که اگه قراره در آینده احتیاجی به چنان شبکه ای باشه، بد نیست از حالا به فکر خرید باشه.)»
شما به این می گید صحبت مطلق؟ من می گم. و معتقدم حرف درستی است.
اما منظور من از حرف قبلیم چی بود؟
«تا زمانی که واقعا نیازی وجود نداره، مسلما عقل حکم می کنه که (اصول حکم می کنند که) برنامه طوری نوشته بشه که حتی الامکان از کارهای زمانبر اجتناب شود.»

توجه دارید که الآن آقای ehsane اینکار رو کردن. و من برداشت می کنم که کارفرمایشان هم راضی شده. بنابراین لزوم چندانی به پیاده سازی های سنگین نیست. یعنی کارفرما هم چنین انتظاری ندارد. بازهم توجه کنید که تا قبل از اینکه خود آقای ehsane در این مورد صحبتی کنند، من (و سایر دوستان) فرض رو بر این گذاشتیم که چاره ای جز انجام چنان عملیاتی نیست. برای همین هم تا قبل از آن فقط تاکید من روی این بود که راه حل من (Cahce که آقای کشاورز پیاده سازی آن را نوشتند) و راه حل آقای Touska (فشرده سازی) تنها راه حلهای قابل قبول هستند. (البته گفتم؛ در صورتی که مجبور باشند چنان کاری را انجام دهند)
------------------------------------------------------------------------
در مورد مزایایی که برای فایل سرور نوشتید، جالب است که اکثر آنها از طریق SqlServer قابل انجامند و بسیار هم کار ساده تر است. (البته در بعضی موارد معدود، اگر خودتان یک SqlServer بنویسید اندکی انعطاف پذیری بالا می رود!!!) مثلا خود SqlServer امکان توزیع دیتابیس، پشتیبانگیری جزیی از فیلدها و ... را دارد. حال می خواین خودتون از اول همه رو بنویسین؟ خب من مخالفتی ندارم.
در مورد پشتیبان گیری نکته دیگری هم هست. آنهم اینکه شما از فایلهای تصویری پشتیبان نمی گیرید؟ مهم نیستند؟ اگر مهم نیستند که کار درستی می کنید.
اما یک چیز دیگر هم در SqlServer نوشتند که کمک فراوانی می کند. آنهم پشتیبانگیری افزایشی است. یعنی اگر چیزی از زمان آخرین پشتیبانگیری تغییر نکرده باشد، از آن پشتیبان نمی گیرد. (فقط تفاوتهای دیتابیس کنونی با نسحه پشتیبان ذخیره می شوند) فکر می کنم اینکار SqlServer دیگه تمام مشکلات پشتیبانگیری رو حل می کنه. نه؟

vcldeveloper

یک شنبه 24 مهر 1384, 04:31 صبح

خود SqlServer امکان توزیع دیتابیس، پشتیبانگیری جزیی از فیلدها و ... را دارد. حال می خواین خودتون از اول همه رو بنویسین؟
فکر نکنم SQL Server غیر از امکان File Group (که اون هم به نوعی شبیه سازی RAID هست)، امکان دیگه ایی برای توزیع دیتابیس داشته باشه.

m-khorsandi

یک شنبه 24 مهر 1384, 08:27 صبح

درود
منظور از DB های توزیع شده دقیقا مفهوم Distributed Database هست.

m-khorsandi

یک شنبه 24 مهر 1384, 08:36 صبح

اما یک چیز دیگر هم در SqlServer نوشتند که کمک فراوانی می کند. آنهم پشتیبانگیری افزایشی است. یعنی اگر چیزی از زمان آخرین پشتیبانگیری تغییر نکرده باشد، از آن پشتیبان نمی گیرد.

اگه منظورتون Differential Backup هست باید عرض کنم که اون پشتیبان گیری تفاضلی ست نه افزایشی!

Naficy

دوشنبه 25 مهر 1384, 06:15 صبح

اگه منظورتون Differential Backup هست باید عرض کنم که اون پشتیبان گیری تفاضلی ست نه افزایشی!
بله منظورم همینه. دزست می گین. پشتیبانگیری تفاضلی صحیحتره. (البته اشتباه لپی بود، ولی شاید هردو صحیح باشن. منظور اینه که فایلهای پشتیبان ایجاد شده رو؛ هنگام بازیابی باید به دیتابیسی - که قبلا از روی فایلهای پشتیبان قبلی بازیابی شده - اضافه کرد. هر فایل پشتیبان نسبت به اطلاعات فایلهای قبلی اطلاعات افزایش یافته رو ذخیره می کنه)

m-khorsandi

دوشنبه 25 مهر 1384, 14:18 عصر

بله منظورم همینه. دزست می گین. پشتیبانگیری تفاضلی صحیحتره. (البته اشتباه لپی بود، ولی شاید هردو صحیح باشن. منظور اینه که فایلهای پشتیبان ایجاد شده رو؛ هنگام بازیابی باید به دیتابیسی - که قبلا از روی فایلهای پشتیبان قبلی بازیابی شده - اضافه کرد. هر فایل پشتیبان نسبت به اطلاعات فایلهای قبلی اطلاعات افزایش یافته رو ذخیره می کنه)

اگه مبنا تعریف شما از Differential Backup باشه، بله شما درست میگید، در صورتی که اینطور نیست.
در Differential Backup تغییرات سنجیده میشه، حال این تغییرات میتونه حذف/اضافه کردن اطلاعات باشه یا تغییراتی
روی ساختار DataBase، به همین خاطر پشتیبانگیری تفاضلی صحیح است.

Naficy

سه شنبه 26 مهر 1384, 06:09 صبح

ظاهرا داریم بدجوری از مبحث تاپیک دور می شیم...
--------------------------------------------------------------------
چه فرقی می کنه. پشتیبانگیری تفاصلی احتیاج به بازیابی افزایشی داره. و اطلاعات درون فایل، علاوه بر "تغییرات تفاضلی مابین دو زمان" همچنین "تغییرات محتاج به افزودن به یک پشتیبان" هستند.
اماشاید مساله تو این باشه که پشتیبانگیری تفاضلی ترجمه جالبی نباشه. چون شاید کلمه Differential روی "تغییر" تاکیدی داره که تفاضلی نداره. افزایشی و تفاضلی همواره باهم استفاده می شن. وقتی تفاضل دوتا چیز رو می گیرین، باید اونو به یکیشون بیفزایید تا اون یکی بدست بیاد...!!!
اما همچنان موافقم که "تفاضلی" لفظ صحیحتریه.