View Full Version : کند شدن بازخوانی اطلاعات از mysql
resatak
سه شنبه 05 آبان 1388, 10:49 صبح
با سلام خدمت دوستان محترم من یک مشکل پیدا کردم نمیدونم ایرادش کجاست!!!
یه صفحه به زبان asp نوشتم که از طریق
sql = "Select * from bodycontent where Id='"&request("ID")&"'"
set rs = cn.execute(sql)
if rs.eof then
response.Redirect("index.asp")
end if
با mysql ارتباط برقرار کرده و رکورد مورد نظر از بین حدودا 30 هزار رکورد موجود در جدول مورد نظر بازخوانی میکنه منتها مشکلی که الان وجود داره اینه که خیلی کند این کار صورت میگیره و وقتی که تعداد رکورد زیر 5 هزار تا باشه خیلی سریع این کار انجلم میده میخواسته بدونم که راه حلش چیه که حتی زمانی که رکورد ها به بالای 100 هزار تا هم رسید مشکلی برای سایت پیش نیاد
ممنون میشم بهم تو این زمینه کمک کنید.
resatak
یک شنبه 17 آبان 1388, 22:11 عصر
واقعا راه حلی نداره؟؟
young_man1365
یک شنبه 17 آبان 1388, 22:21 عصر
این کوئری تنها مشکلی که ازش به چشم میاد استفاده از SELECT * هست. از * فقط وقتی استفاده کنید که دقیقا" همه فیلدها باید فراخوانی شوند.همیشه فقط چیزی رو بگیرید که لازم دارید، نه بیشتر! ضمنا" شکل جدول رو بررسی کنید. ممکنه نیاز به نرمال سازی باشه.
resatak
دوشنبه 18 آبان 1388, 16:16 عصر
با تشکر از شما
در مورد select منظورتون اینه بشه select(user-id,name)from درسته ؟
در مورد نرمال سازی همه میشه بیشتر توضیح بدید.
ممنون
young_man1365
دوشنبه 18 آبان 1388, 20:08 عصر
با تشکر از شما
در مورد select منظورتون اینه بشه select(user-id,name)from درسته ؟
در مورد نرمال سازی همه میشه بیشتر توضیح بدید.
ممنون
اگه پرانتزها رو حذف کنید ، درسته:چشمک:
ٍُSELECT user-ID,Name FROM ..................
البته نسخه هایی که من استفاده کردم این شکل دستورات <لیست فیلدها داخل پرانتز> رو قبول نمیکنه و فکر کنم همه نسخه ها همینطور باشه.
در مورد نرمال سازی هم باید بگم این مرحله قبل از پیاده سازی پایگاه داده و هنگام طراحی جدول و فیلدهاش انجام میشه. این کار باعث میشه به هنگام انجام عملیات روی داده های بانک (جستجو و.... ) این اعمال با سرعت بیشتر و بدون اتلاف حافظه و زمان و پردازش تکراری انجام بشه . نرمال سازی بحث مفصلیه و نیاز به تمرین زیادی داره. اگه به کتاب بانک اطلاعات علمی کاربردی نوشته حق جو یا کتاب سیستم های بانک اطلاعاتی نوشته سی جی دیت جلد اول دسترسی داری حتما" فصلهای مربوط به این موضوع رو مطالعه کن. در ضمن بجای انجام دستی میتونی از نرم افزارهای ویژه این کار استفاده کنی که البته نتیجه به خوبی انجام کار بصورت دستی نخواهد بود.
موفق باشید
resatak
سه شنبه 19 آبان 1388, 12:30 عصر
در مورد پرانتز حق با شما بود به عنوان مثال نوشته بودم و دقت نکرده بودم.
در مورد بخش دوم هم واقعا توضیحات کامل و ومفیدی بود واقعا ممنون هستم.
ضمنا یه سئوال داشتم این خبرگزاریها که روزی 200-300 تا خبر دارن یعنی حدودا سالی 100 هزار تا همه خبراشون تو یه جدول میزارن اگر این طوره سرعتش پایین میاد یا نه دستی ماه به ماه آرشیو میکنن چون فکر کنم نوشتن برنامه واسه آرشیو کردنش بعد فراخوانی خیلی پیچیده بشه ؟؟؟
young_man1365
سه شنبه 19 آبان 1388, 18:15 عصر
بحث آرشیو کردن اونقدرا هم که فکر میکنید پیچیده و سخت نیست. بازه زمانی برای آرشیو و نحوه و مکان آرشیو همگی بستگی به نوع پایگاه داده و پیکربندی اون داره. با چند مثال سعی میکنم منظورمو واضح بگم.
همون مثال سایت خبری رو که فرمودید در نظر بگیرید... اگه پایگاه داده ورودی خیلی زیادی داشته باشه آرشیو کردن منطقی بنظر میرسه و طراحی که با mysql پایگاه رو ساخته ممکنه اینجوری عمل کنه: دو جدول رو در نظر میگیره:
1- جدولی که حاوی داده ها و اخبار جدیده و معمولا" موتور این جدول از نوع myisam و یا innodb انتخاب میشه.
2- جدولی که داده های قدیمی رو نگهداری میکنه و موتورش از نوع ARCHIVE هست. برای اختصاص موتور هنگام ساخت جدول اینجوری عمل میکنیم. مثال:
CREATE TABLE ARCHIVE2009 (
...
لیست فیلدها
...
)
ENGINE=ARCHIVE;
این موتور مناسب برای ذخیره اطلاعات آرشیوی است و توصیه میشه برای آرشیو کردن از اون استفاده کنین. حالا چطور آرشیو انجام بشه؟ این کار میتونه بوسیله برنامه نویس انجام بشه یعنی به همراه هر خبری که ذخیره میشه یه فیلد حاوی زمان اون هم ذخیره بشه و بدین صورت برنامه نویس میتونه برنامه رو طوری بنویسه که آخر هر روز خبرهای N روز پیش به جدول آرشیو منتقل بشه که این کار هم سخت نیست. اگه به نام جدول در مثال بالا توجه کرده باشید ARCHIVE2009 ! میشه برای هر سال یا هر بازه زمانی خاص یه جدول آرشیو مخصوص یه اون دوره ساخت.
اما آرشیو کردن برای پایگاه های پر کار همیشه مفید نیست.
با یه مثال توضیح میدم: یه سایت دانشگاهی مجازی رو در نظر بگیرید. فرض کنیم این سایت در هر استان چند واحد داره و هر واحد این دانشگاه ها هزاران دانشجو داره. همه ی این دانشجو ها هر ترم انتخاب واحد میکنند و اطلاعات کلاسها و نمرات اونها در این پایگاه ذخیره میشه. برای این مورد آرشیو کردن اصلا" عاقلانه نیست چون زمان انتخاب واحد که میرسه لازمه سابقه تحصیلی هر دانشجو از پایگاه بازخوانی بشه. برای این جور موارد از بانکهای اطلاعاتی توزیع شده استفاده میشه. یعنی اینکه ظاهرا" یک پایگاه اصلی و یک سایت واحد وجود داره، اما در عین حال اطلاعات هر واحد در یک پایگاه داده فرعی در استان مربوط به اون ذخیره میشه. یعنی اطلاعات یه دانشجو در واحد کرج در پایگاه مربوط به استان تهران ذخیره شده و اطلاعات دانشجوی واحد مشهد در پایگاه خراسان. در عین حال هر دو دانشجو هنگام کار با سایت ، سیستم رو یکپارچه میبینند و فکر میکنند اطلاعات هردو اونها در یک جا ذخیره میشه!... فکر کنم سیستم دانشگاهی گلستان اینجوری باشه.
بحث سیستمهای توزیع شده واقعا" پیچیدست و نیاز به مطالعه زیادی داره.
ببخشید بحث رو به اینجا کشوندم اما فکر کردم برای درک کاربرد آرشیو لازم باشه.:چشمک:
امیدوارم مفید بوده باشه
موفق باشی
resatak
چهارشنبه 20 آبان 1388, 10:55 صبح
واقعا متشکرم از توضیحات کامل و مفیدتون
دقیقا مثله هم اینجاست که درست کردن جدول ارشیو و انتقال رکورها به اون جدول مشکلی نداره ولی فرض کنید ( بر طبق مثال همون خبرگزاری) شما امروز یک خبر ایجاد میکنید و خوب لینک این خبر بر اساس id اون تو دیتابیس تعریف میشه یعنی بازدید کننده همچین آدرسی میبینه news-mode.asp?id=1306
ولی فردا که این خبر آرشیو بشه دیگه این خبر تو این جدول نیست و رفته به همون arshive2009 که خوب به نظر میرسه نمیشه دوباره همه رو تو این جدول بریزیم و بعد از مدتی باید یکی دیگه تعریف کنیم !!!
یعنی باید تو کد نویسی اون صفحه چه کار کرد ؟
ضمنا میتونید بگید فرق اون دو تا موتور چیه ؟
young_man1365
چهارشنبه 20 آبان 1388, 14:00 عصر
ببخشيد من asp كار نكردم و باهاش آشنايي ندارم و نميدونم روش ساخت لينكش چطوره . ولي در مورد مشكل لينك كه شما فرموديد اينجوري گرفتم كه مشكل شما در شناسايي جدول حاوي خبره! يعني اينكه از كجا بدونيم خبر رو تو كدوم جدول پيدا كنيم؟ اگه مشكل شما اين بود بايد بگم هر طراح ميتونه روش خودشو داشته باشه. يك روش ساده ممكن ميتونه اينطوري باشه:
ميشه يه جدول مثلا" به نام IND شامل id خبر و نام جدولي كه اخبار درون اون قرار داره ساخت. اين جدول آيدي و مكان همه داده هاي مربوط به همه جداول آرشيو و اخبار جديد رو در خودش داره . به هنگام آرشيو كردن يك خبر علاوه بر انتقال داده ها به جدول آرشيو، نام جدول آرشيو هم در جدول IND كه توضيحشو دادم update ميشه. اينجوري براي پيدا كردن مكان يك خبر ابتدا برنامه سراغ جدول IND ميره و مكان خبر با آيدي مورد نظر رو پيدا ميكنه و سراغ اون جدول ميره.
در اين روش ميشه به جاي نام جدول از تاريخ درج خبر هم استفاده كرد كه در اين صورت برنامه با خوندن تاريخ هر خبر سراغ جدول آرشيو اون تاريخ ميره. البته اين روش كار رو كمي كندتر ميكنه كه با تعريف انديس براي جدول مشكل تا حدودي حل ميشه.
سوال دوم:
كاربرد موتورهاي نوع اول innodb , MYISAM كه مشخصه و در تاپيك هاي قبلي مفصل بحث شده.
اما موتور ARCHIVE ! اين موتور براي كار با جداولي كه داده هاي بسيار زياد رو نگهداري ميكنه طراحي شده. آرشيو از انديس استفاده نميكنه تا در مصرف فضا صرفه جويي بشه. به همين خاطر عمليات در جداول آرشيو نسبتا" كندتره. اما كندتر بودن تنها به اين دليل نيست. وقتي شما با دستور insert داده ها رو وارد جدول آرشيو ميكنيد، داده ها فشرده ميشن و سپس وارد جدول ميشن. اين موتور از فشرده ساز zlib استفاده ميكنه. يه نكته مهم! موتور آرشيو از دستورات SELECT , INSERT پشتيباني ميكنه اما DELETE , REPLACE , UPDATE در اين موتور پشتيباني نميشه. دليلش هم كاربرد نداشتن اين اعمال روي داده هاي آرشيويه.
resatak
چهارشنبه 20 آبان 1388, 14:53 عصر
با تشکر از توضیحاتتون واقعا ممنونم خیلی کامل بود و مشکل منحل کرد.
فقط یک سئوال دیگر در مورد موتور آرشیو آیا هنگام فراخوانی هم این موتور کند عمل میکنه یا فقط هنگام insert ?
young_man1365
چهارشنبه 20 آبان 1388, 18:42 عصر
توجه کنید که این موتور کند نیست و اختلاف عملکرد اون با موتوری مثل innodb و myisam چندان زیاد نیست (معمولا" محسوس نیست). منظور من از کندتر بودن، نسبت سرعت عمل به این دو موتور بود.
برای سوالی که پرسیدید باید بگم: در موتور آرشیو وقتی یک عمل فشرده سازی برای ورود داده صورت میگیره، داده ها برای بازخوانی نیاز دارند که از حالت فشرده شده خارج بشن که این عمل هم تقریبا" به اندازه فشرده سازی داده ها زمان میبره. بنابراین فراخوانی هم مثل insert کردن زمانی برای خارج کردن داده های فراخوانی شده از حالت فشرده نیاز داره.
موفق باشید
vBulletin® v4.2.5, Copyright ©2000-1404, Jelsoft Enterprises Ltd.