"Сега - как бихте се справили с описания проблем?"
С прости плоски файлове.
Ето защо
Имате 2 000 000 субекта. Разделяне въз основа на номер на обект:
level1= entity/10000
level2= (entity/100)%100
level3= entity%100
Всеки файл с данни е level1/level2/level3/batch_of_data
След това можете да прочетете всички файлове в дадена част от директорията, за да върнете проби за обработка.
Ако някой иска релационна база данни, тогава заредете файлове за даден entity_id в база данни за тяхна употреба.
Редактиране На номера на дните.
-
date_id/entity_idправилото за уникалност е не нещо, с което трябва да се работи. Това е (а) тривиално наложено върху имената на файловете и (б) ирелевантно за заявки. -
date_id"преобръщане" не означава нищо - няма заявка, така че няма нужда да преименувате нищо.date_idтрябва просто да расте без граници от датата на епохата. Ако искате да изчистите старите данни, изтрийте старите файлове.
Тъй като нито една заявка не разчита на date_id , никога нищо не трябва да се прави с него. Това може да бъде името на файла за всичко, което има значение.
За да включите date_id в резултантния набор, запишете го във файла с останалите четири атрибута, които са във всеки ред на файла.
Редактиране при отваряне/затваряне
За да пишете, трябва да оставите файловете отворени. Правите периодични изтривания (или затваряте/отваряте отново), за да сте сигурни, че нещата наистина отиват на диска.
Имате два избора за архитектурата на вашия писател.
-
Имайте един-единствен процес на „писател“, който консолидира данните от различните източници. Това е полезно, ако запитванията са относително чести. Вие плащате за обединяване на данните по време на запис.
-
Отворете няколко файла едновременно за писане. Когато правите заявка, обединете тези файлове в един резултат. Това е полезно, тъй като заявките са сравнително редки. Вие плащате за обединяване на данните по време на заявка.
