من به شخصه باشم کاری که میکنم اینه که با یک حلقه تمام ردیف ها رو
SELECT
میکنم و اضافه میکنم به یک لیست.
در عین اضافه کردن. یه شرط میزارم. اون شرط اینه که اگر این ردیف قبلا بوده و در نتیجه در لیست هست، این اخری رو پاک کن.
If selected in list of selected :
اون ردیف رو حذف میکنم.
فقط فکر میکنم بهتر باشه
Commit
رو اخرش انجام بدید.
صرفا کنجکاو شدم یه راه حلی به ذهنم اومد نمیدونم چقدر خوبه.
ولی فکر کنم هر چقدرم طول بکشه نتیجه رو بده.
مثلا مینی بچ های هزار تایی از دیتا بیس رو بگیریم همون کار رو انجام بدیم روی همشون.
بعد از هر مرحله مینی بچ هم
commit
و
exit
یا حالا هر روش دیگه که رم خالی بشه برای مرحله بعدی تا مینی بچ ها تموم بشه.
اینطوری در فاز اول توی هر مینی بچ هر چیزی یکبار وجود داره.
حالا هر مینی بچ رو با اون یکی مقایسه میکنیم ببینیم تکراری هست یا نه.
در پایان فاز دو حس میکنم نتیجه مطلوب رو داریم.
از اونجا که مقایسه
A & B
مثل
B & A
هست میشه این حالات رو هم گفت که کلا انجام نده. بستگی داره که رم چقدر بکشه. هر چی بیشتر بکشه مینی بچ ها بزرگتر.
این روش خوبی نیست .. علاوه بر اینکه O(n^n) میتونه داشته باشه.. و میتونه این پروسه رو تکرار کنه و تضمین هم نیست که تو هر مرحله .. مینی بچ ها کاهش پیدا کنن .. و در نتیجه تو مرحله اخر که باید همشونو باهم مقایسه کنی بازم همون میزان دیتا باید لود بشه تو رم . ..
بله همونطور که گفتم روش عملی خوبی نیست.
ولی مشکل رم فکر نمیکنم داشته باشه.
چون قبلا چند میلیون بود.
الان مثلا صرفا دوتا پنج هزار تایی رو در هر مرحله مقایسه میکنه و رم رو خالی میکنه، برای همین هم گفتم مراحل انجام شده رو توی یک فایل ذخیره میکنیم چون وقتی
Quit
میکنه اپ بسته میشه متغیر ها هم میپره.
یک سوالی که دارم اینه که موقع اجرای یک کد پایتون چه چیزایی توی رم نگه داشته میشه؟
مثلا اگر
A = list of million chars
باشه بعد
A = [1]
کنیم فقط دومی توی رم میمونه؟
خب اینجوری که O(n^n هست 😅 و باید هی تکرار شه . ..
فک کردم حداقل جمع نتایج هر n مرحله باهمدیگه میخایید با مرحله تکی بعدی مقایسه کنید .. که روش بدی نبود .. و همه تکراری هارو میشد با ۱دور طی شدن پیدا کردن .. ولی خب اخرش (حداکثر کل داده ها (درصورت تکراری نبودن هیچکدوم) و حداقل 70درصد وارد رم میشد)
سوال دومتون . بستگی داره اون A چطور خونده بشه .. .مثلا ormهای پایتون اکثرا اعتقاد به lazy-loading دارن .. شما ۱تیبل هرچقد دیتا رو هم بخونید نمیاره تو رم .. تا وقتی که دقیقا بهش دسترسی پیدا کنید با ایندکس یا سعی کنید از حالت query set درشون بیارید ..
اما فرض کنید فایل خوندید .. خوندن فایل lazy نیست .. مگر خودتون lazy پیاده سازیش کنید .. و nمگابایت/گیگابایت از یه فایل رو بخونید ..
ایده این بود که هر مینی تا جایی که ممکنه بزرگ باشه. پس اصلا شاید کلا ده تا مینی بچ باشه. خلاصه اینکه نمیشه جمع کنیم چون جمع کنیم ارور رم میده.
اگر بشه متغیر ها رو خالی کرد تا رم خالی شه که خود برنامه انجام میده و تموم. اگر نشه، دو راه داره.
یا اینکه برنامه در هر مرحله تموم بشه و سیستم عامل هی اجراش کنه با فایل کمکی که بهش میگه از کجا شروع کنه.
یه روش دیگه هم هست نمیدونم توی پایتون میشه انجام داد یا نه.
توی متلب دو تا فایل کد رو توی یک دایرکتوری میزاشتیم، به داده های هم دسترسی داشتن.
در این صورت اگر مثل متلب باشه، میشه دوتا کد برادر و مشابه نوشت که هر کدوم در اخر ارجاع میده به داداشش.
اون اخری رو نفهمیدم متلب و داداش چیکار کرد 😂
مشکل سر O(n^n هست .. و کندی پروسس .. هر مینی بچ باید با تمام بچ های دیگه مقایسه بشه .. .همین .. راه بهینه ای نیست . ...ذخیره نتیجه هم کمکی به پروسس مینی بچ های بعدی نمیکنه .. فقط مقایسه هر مینی بچ با بقیه هست که میتونه بصورت تضمینی داده های تکراری شو ازش در بیاره .. .و در نهایت بصورت تمیز ذخیرش کنه . ..
یکی مشکلش رو گفته سی و شش میلیون ردیف هم داره. جوابش این کد رو دادن. انگار جواب هم داده. روش شما رو من یطور دیگه فرض میکردم. بله خیلی خوبه. فقط برای اینکه حسودم، میگم اگر محدودیت دیسک داشته باشیم چی ؟ 😜😜😜😝
این اوراکله ؟ کوئری کامل نیست .. جای خالی زیاد داره ..
,, rowid ادرس فیزیکی رکورد هست ..
گروپ بندی کرده ایدی و هش بدست اومده از رکورد رو و مینیمم هم به معنای کوچکترینه هست(یعنی اولین رکورد از رکوردای تکراری)
Un feed público abierto del índice de búsqueda
ChatCrawler — el “Google del Telegram público”; se actualiza a medida que se rastrea la comunidad.
Las horas se muestran en UTC.