Какой тип данных MySQL наиболее эффективен для длинных цепочек?

Question

Мне нужно хранить в таблице MySQL длинные битовые строки, которые могут быть длиной до 32768 бит.Эти данные не нужно будет индексировать или полнотекстовый поиск в любое время.Если я правильно прочитал, этот размер должен соответствовать как моему max_packet_size, так и пределу размера строки @ 65k.

В идеале я хотел бы хранить строки (и вставлять их) в формате 0b, ноэто не является обязательным требованием ... все, что даст мне данные 1: 1 / размер на диске, было бы замечательно.

BLOB, кажется, не выполняют свою работу достаточно хорошо, поскольку строка состоит только изи нули ('010101010101') видны не отличающимися от обычного текста и стоят мне L байт + 2. BIT () будет идеальным, но ограничен только длиной до 64 бит.

Хотя большая часть данных(90% +) было бы достаточно представлено в беззнаковом Bigint, оставшиеся 10% строк побуждают меня найти более элегантное решение, чем их логическое разделение (т. Е. Поиск вторичной таблицы, если она не найдена в первой, вторичной таблице с использованиемBLOB для оставшихся 10% строк и т. Д.).

Дополнительным бонусом будет любой тип, разрешающий побитовые операции, но если нет, то это так же простоy сделано вне сервера MySQL.

Какой тип данных наиболее эффективен для этой цели?

Answer 1

Я бы сказал, что это в основном зависит от вашего шаблона доступа. Если вы можете позволить себе читать / записывать всю цепочку битов при каждом доступе, тогда varbinary (4096) будет работать нормально и быть достаточно компактным (только 2 байта служебной информации для всего поля). В этой модели один бит на стороне приложения действительно представлен одним битом в хранилище данных, и клиентское приложение должно интерпретировать его как цепочку битов (выполнение побитовых операций и т. Д.)

Если вы хотите оптимизировать немного больше, вы можете представить таблицу с bigint и varbinary (4096):

create table dummy (
   dummykey int not null,
   bit1 bigint null,
   bit2 varbinary(4096) null,
   primary key(dummykey)
);

Только одно из двух полей не является пустым для данной записи. Если бит1 не равен нулю, он может хранить 64 бита. Для больших цепочек битов бит1 равен нулю, а бит2 используется вместо него. Клиентское приложение должно быть достаточно умным, чтобы обрабатывать все побитовые операции (обращая особое внимание на проблемы со знаком / без знака с битом 1).

Answer 2

Полагаю, вам нужен тип BLOB. Он может представлять двоичные строки размером до 2 ^ 16 байтов и имеет накладные расходы 2 байтов на запись (если L - длина в байтах значения, L + 2 байт - это его размер на диске).

Затем, если вы действительно хотите оптимизировать, используйте две таблицы, одну с BLOB, а другую с TINYBLOB (строки длиной до 2 ^ 8 байт , 1 байт служебные данные), затем СОЕДИНИТЕ их вместе в ПРОСМОТРЕ или во время SELECT.

Если вы хотите оптимизировать еще больше, используйте третью таблицу с BIGINT (это позволит хранить двоичные строки размером до 58 бит , так как оставшиеся 6 будут необходимы для хранения длины двоичной строки ).