Логично, но углерод из CO2 при этом фиксируется в виде деревьев, трав и прочей зеленой биомассы. Большинство этой биомассы короткоживущее и быстро съедается/разлагается, отдавая углерод обратно в CO2. Надолго он фиксируется в деревьях, но только что-то не слышно, чтобы леса грозили заполонить планету. К тому же леса гниют с тем же успехом, только попозже. Тут для компенсации сжигания угля нужно чтоб шел процесс «создания угля» с такой же скоростью. Однако, даже в Карбоне скорость отправки лесов на создание угля была гораздо меньше текущего потребления. 65 млн лет на накопление и 400 лет на потребление (с учетом будущего потребления) — скорости явно различны.
600 Мбайт на 6 миллионов записей это по 100 байт на одну запись.
Если применить нехитрое наблюдение, что все номера представляют собой вид 79xxx-???-???, то можно завести одну таблицу первичного поиска на 1000 записей для поиска по xxx части. Содержать эта таблица будет указатели на таблицы вторичного поиска, в которых содержится ???-??? часть и 1 байт для обозначения оператора.
???-??? можно хранить как BCD.
Получаем расход памяти в первичной таблице 1000*sizeof(pointer) = 8000 байт для 64 битного приложения.
По вторичному поиску получаем 1000*sizeof(пустой vector) + (3 байта для номера+ 1 байт на обозначение оператора)*количество номеров всего = 1000*20+4*6*10^6= 24020000 байт.
Добавка 8кбайт таблицы первичного поиска на результат почти не влияет и получаем 4,003 (чуть больше 4) байт на запись.
Поиск будет двоичным по вторичным таблицам, но за счет заметно меньшего объема памяти будет заметно быстрее, имхо. т.к. узким местом будет обмен с памятью, поскольку в кеш это все не влазит.
Можно разбить как 79xxx-xx?-???, и получить меньше 4 байт на запись, но тогда записи в таблицах вторичного поиска будут по 3 байта и не будут выровнены. Это может негативно сказаться на производительности.
Если применить нехитрое наблюдение, что все номера представляют собой вид 79xxx-???-???, то можно завести одну таблицу первичного поиска на 1000 записей для поиска по xxx части. Содержать эта таблица будет указатели на таблицы вторичного поиска, в которых содержится ???-??? часть и 1 байт для обозначения оператора.
???-??? можно хранить как BCD.
Получаем расход памяти в первичной таблице 1000*sizeof(pointer) = 8000 байт для 64 битного приложения.
По вторичному поиску получаем 1000*sizeof(пустой vector) + (3 байта для номера+ 1 байт на обозначение оператора)*количество номеров всего = 1000*20+4*6*10^6= 24020000 байт.
Добавка 8кбайт таблицы первичного поиска на результат почти не влияет и получаем 4,003 (чуть больше 4) байт на запись.
Поиск будет двоичным по вторичным таблицам, но за счет заметно меньшего объема памяти будет заметно быстрее, имхо. т.к. узким местом будет обмен с памятью, поскольку в кеш это все не влазит.
Можно разбить как 79xxx-xx?-???, и получить меньше 4 байт на запись, но тогда записи в таблицах вторичного поиска будут по 3 байта и не будут выровнены. Это может негативно сказаться на производительности.