(Пожав плечами) Если считать, что у Вас будет 100 байт в среднем на запись, и для идэнтификацыи конкретной записи будет достаточно информацыи из одного поля, и по этому полю будет организован индэкс типа B-Tree с размером записи индэкса в 20 байт -- то Вам потребуется 3000000000*(100+20) = 360000000000 B = 360000000000/1000000000 GB = 360 GB места на жёстком диске. Если считать размер страницы в 8 KiB, то на страницэ индэкса будет около 400 записей, а в среднем для поиска записи потребуется прочитать log_400(3000000000) = 3.64... страницы. Ещё потребуется прочитать страницу с самой записью, плюс можно немного накинуть на накладный расходы файловой системы -- в общем, придётся читать около 5 страниц. Страницы будут распределены достаточно произвольно по диску (и читаться строго последовательно -- так как каждая следующая требует прочтённой предыдущей), но каждая из них скорее всего будет лежать в соседних секторах, так что, скорее всего, каждая страница будет читаться с HDD примерно время, соответствующее среднему времени позицыонирования головки диска (время на чтение нескольких последовательных секторов пренебрежымо мало по сравнению с временем позицыонирования) -- или, при среднем времени позицыонирования невыдающихся жёстких дисков в 3-4 мс -- это будет 15-20 мс на одну запись.
Это нижэ Раскинских 50мс как времени реакцыи, которая считается "мгновенной" и дажэ не вышэ моих личных 20мс, на которых я точно не могу различить два последовательных события. Таким образом, для человека такая скорость доступа можэт оцэниваться как очень быстрая.
Так что для хранения и быстрого доступа к записям поштучно при указанных предположэниях (размер записи, наличие используемого индэкса, выборка по одной, использование одним человеком в каждый момент времени) -- подойдёт дажэ довольно слабый современный офисный компьютэр.
|
