BAZlSTmayton И КПД не могут увеличить.

КПД как раз увеличивают и выбросы СО2 постоянно снижают
Баз. Друг. Ты не поверишь. КПД современного ДВС составляет 20-30%.
У дизелей - чуть побольше. Но ты вдумайся в эти цифры1!!

Это эпик фейл!! Чувак! Мы более 100 лет обогреваем атмосферу! Равносильно
тому что ездим на паровозах! И это не смотря на комьютерное моделирование
взрывов камеры, новые идеи в механике поршней роторы, цилиндры и прочие
двигатели Ванкеля!

Ничего! Полный нуль!

BAZlSTЧитай
http://www.motorpage.ru/discussion/JEvoljucija_DVS/JEvoljucija_DVS_dostigla_pika.html
Не верю я в эти Ё-мобили и в 45%. Здесь какой-то фундаментальный подвох.
Если они принципиально меняют ДВС на ротор то это уже другой класс авто.
Со всеми вытекающими вопросами. Как оно заводится? Как охлаждается?
Как его можно обслуживать?

BAZlSTПрогресс строится на тех кто верит , а не на тех кто не верит.
Еслиб мы сидели и зачитывались книжками предшественников, так бы и сидели на паровой тяге
по сегоднешний день
Пфф... прогресс. А я когда в школе учился, наивный верил что у машин КПД - 90-95%.

Не разбивай мои детские идеалы!

Кхе... вобщем так. В продолжение банковских налоговых номеров.

Уточню постановку. Это embedded db, которая должна подняться на мобильном устройстве.
В условиях ограниченнной памяти. Или даже не embedded db а скорее витрина доступа
к данным которые были выгружены из продакшен ДБ.

Основная цель - выбрать методы упаковки 1 таблицы с небольшим числом колонок.
В данном случае - 1 колонка.

На глаз, ничего не меряя составил список тестов алгоритмов которые надо будет прогнать.
Всё пока приблизительно +- 20% погрешности допускаю.

AlgorithmTable SizeCompressed ratioCreation timeRandom access time Iterator supportOrdered iterationUpdate/deleteFlat Table(CSV)33M 1.0++-Gzipped flat table10M 0.33++(forward)-Bitmap4M?+++Gzipped differencial numbers(LZW)??++(forward)-Ariphmetic differencial numbers??++(forward)-RadixTree??+?+(возможно)Bloom Filter(adaptive accuaracy)??---Bloom Filter(with exception table)??---

Тестовые данные были получены как генерация случайных ИНН в диапазоне от 1947 до 1996 года рождения
физ.лиц с пропорциональной гистограммой распределения групп в количестве 10% трудоспособного населения страны.

Это прибл. 3.2 млн rows.

В формате CSV - это 33М. Что еще не учтено? Не учтена гистограмма регистраций в налоговой.
Она нелинейна по годам. И не учтен метод генерации трехзначного серийного сомера. Я брал
просто последовательность от 0 до 999.

Не учтено существование "битых" ИНН с неровной CRC. Фактически они существуют в небольшом
количестве но я на них пока забил.

По поводу алгоритмов.

Gzipped differencial numbers - пока не знаю как пред-обработать. Подавать на вход
текстом - как-то некошерно. Это лишняя трансформация. Нужен более нативный подход.

Ariphmetic differencial numbers - у меня реально нету.
Где его взять имплементацию в Java да еще и со свободной лицензией
- пока не представляю. Но это была бы конфетка.

На последние два я делаю ставку. Они должны выехать в первое место
после битмапы по степени сжатия.

С точки зрения удобства транзакций Блум представляет собой самый тяжелый случай.
Итератора нет. И принципиально (!) невозможно сделать delete. Можно грохнуть всё
и прогрузить заново но меня это вобщем-то устраивает т.к. embedded DB будет
read only.

Есть также эффект стохастичных ложных срабатываний на большом количестве ключей
но я буду с этим бороться пользуясь тем что множество ИНН - счётное а не бесконечное
и я могу прогнать тест по всем номерам и выявить ложные и внести их в exceptions
либо просто подрегулировать коэффициент размера и количества ключей.

Вот вобщем-то и всё. Почему я взял ИНН ? Пох. Я мог брать любые базы которые
могут быть востребованы (в планах поддержать DB Maxmind, DB Vendors hardware address, DB префисов мобильной
и городской телефонии а также (няшечка!) БД Российских налоговых номеров.
У них там немножко хитрее и разрядность повыше. Ukranian ИНН просто попались
под руку первые.

Мне нужна числовая оценка. Что за ячейки? Сколько каждая из них займет? Сколько будет в сумме
с учётом всяких эффектов экстента и служебных данных.

Хм.. всё равно не могу прикинуть размер.

Я не вижу особого резона бить по дням.

Например ты группируешь



По дням.

29347 *** * *
29348 *** * *

Но я с таким-же успехом могу групиировать по десятку дней.

2934* *** * *

И получу тоже какой-то бенефит. Весь спор в том кто выгадает больше.

RadixTree это всё обобщает до невообразимых высот.

Правда у меня к сожалению нет его имлементации которая сериализирует дерево на диск.
Без этого оценить трудно.

По поводу Serial. Забудь что я говорил про sequence. Никакой последовательности там нет.
В силу неразберихи и бардака в налоговых службах. Скорее всего Киев делегировал
областям поддиапазоны (пример Харьков [200..250], Днепропетровск [250...310] e.t.c).
И вводили как бог даст. Централизованной БД не было. Я помню тот день когда я пришёл
в обл. исполком. и какая-то тётка вбивала в ДБФ-аля-Турбо-Вижн налоговые анкеты.
И никаким модемом с сеткой и близко не пахло.

Хм..

3.2 млн * 3 * 4 байта = 38M.

Многовато для мобильного девайса. Да и в память прогружать нет особого смысла.
Я ведь не гонюсь за наносекундами. Мне хоть клиент будет ждать 3-5 сек. пофиг.
А если ему крутящуюся анимацию рисовать то и вообще согласен минуту терпеть.