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

Question

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

В идеале я хотел бы хранить строки (и ВСТАВИТЬ их) в формате 0b, но это не является обязательным требованием ... все, что даст мне существенно 1: 1 данные на диске, было бы здорово.

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

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

Дополнительный бонус будет любого типа, который разрешает побитовые операции, но если нет, это также легко сделать за пределами сервера 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 имеет значение null, а вместо него используется бит2. Клиентское приложение должно быть достаточно умным, чтобы обрабатывать все побитовые операции (уделяя особое внимание подписанным/неподписанным вопросам с бит1).

Answer 2

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

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

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