Какую СУБД выбрать для хранения одной большлй таблицы?

Question

[StrangeAttractor]

Будет одна большая (от нескольких миллионов до десятков миллионов записей, полей не много и сами поля сравнительно маленькие, объём таблицы в гигабайтах — ну те же от нескольких гигабайт до нескольких десятков гигабайт (если ткнуть пальцем в небо глядя на предыдущие реализации (на MySQL InnoDB))) таблица. Первичный ключ — составной из нескольких естественных ключей (типа кода страны по ISO 3166, года, и т.п.).

Надо иметь возможность относительно быстро делать из неё произвольные выборки по любым обычным логическим фильтрам по всем полям, очень желательно иметь индексы по колонкам первичного ключа для быстрой выборки (заостряю на этих вещах внимание т.к., вроде, не во всех NoSQL это есть). Записи практически никогда не меняются, только добавляются, обычно большими пачками. Клиентов немного (не high-load), но высокая скорость лишней не будет.

Желательно, чтобы одну и ту же базу (в смысле файлы, в которых она хранится) можно было без труда перетаскивать с компа на комп и использовать под разными ОС (скажем в MySQL такого добиться, вроде, не просто).

Основной язык программирования в проекте — Scala, основная платформа — 32-bit x86 (т.е. объём оперативной памяти в общем случае, на сколько я понимаю, ограничен двумя-тремя гигабайтами).

Рассматриваю и SQL и NoSQL варианты. Опыта в NoSQL — абсолютный ноль, так что не судите строго.

Заранее спасибо за подсказки.

Answer 1

[Vampiro]

Объемы данных принято измерять мега-, гига-, тера-, пета- байтами, но никак не строками. 10 кк строк — это не проблемный объем данных для любой БД, хоть sqlite. До тех пор, пока они вмещаются в оперативку и вы не надумаете масштабировать решение на 2-3 сервера, можете брать то, что вам роднее и ближе. Не выбирайте мускуль, если для вас сложно там скопировать данные с компа на комп.

Куда больше на выбор влияет кластеризация (если есть данные, которые редко дергаются — их лучше положить на винт из оперативки)
Репликация (отказоустойчивость)
Бекапы, миграции, и прочее. А дергать одну табличку… пф)

Comments

[StrangeAttractor]

Хотел коммент написать, получилось, что оформил как ответ. Ниже.

Answer 2

[sphinks]

Немного расскажу про NoSQL: основная фишка этих баз (по крайней мере DynamoDB, с которой я работаю) возможность масштабирования при росте записей с распределением нагрузки на несколько DB серверов. Выборка по произвольному фильтру напрямую будет очень не эффективна и близка к полному перебору, придется придумывать дополнительные «индексные» таблицы. Отсюда и получается если база будет расти и желательно потом это все отрабатывать с примерно той же скоростью, то nosql в облаке был бы неплох, но у вас как я понимаю все локально по идее с одним пользователем, в этом случае смотри на SQL базы.

Answer 3

[StrangeAttractor]

В оперативку вся таблица не влезет как ни крути (вопрос уточнил, спасибо за замечания). Про sqlite, честно говоря, не верю, что она будет сколько-нибудь хорошо, скажем, даже на 5-гигабайтном файле проворачиваться. При желании (которым не горю, ибо Оккам не велит) можно легко осмысленно разбить на несколько частей. Репликация, миграция, бэкапы — грубо говоря не нужны (по природе задачи: ценность хранимых данных очень низкая т.к. всегда можно приостановить production и восстановить из первичного источника, количество клиентов тоже низкое (<100)). Меня интересуют возможности запросов по условиям по колонкам, скорость (работы с многогигабайтной таблицей при использовании не более двух (лучше — одного, чтобы нормально на ноутбуке ворочалось и другим процессам не сильно мешало) гигабайта оперативки) и лёгкость освоения. Когда смотрел сравнения NoSQL-субд смутило то, что некоторые — column-based (как я понимаю то, что мне нужно), некоторые — document-based (как я понимаю (но чую, что как минимум не совсем прав) тут делать запросы по колонкам нельзя), некоторые key-value. Судя по схеме imgur.com/kyahZ мне больше всего подходит Vertica, но она, на сколько я понимаю, платная и не особо поддерживается сообществом.

Comments

[StrangeAttractor]

Это не ответ, это коммент к ответу Vampiro выше — промазал, сорри.

[Vampiro]

Продолжу вам намекать, что любая БД будет нормально работать с этими объемами. Хотя с SQLite, возможно, будет затык:

«When you start a transaction in SQLite (which happens automatically before any write operation that is not within an explicit BEGIN...COMMIT) the engine has to allocate a bitmap of dirty pages in the disk file to help it manage its rollback journal. SQLite needs 256 bytes of RAM for every 1MB of database. For smaller databases, the amount of memory required is not a problem, but when database begin to grow into the multi-gigabyte range, the size of the bitmap can get quite large. If you need to store and modify more than a few dozen GB of data, you should consider using a different database engine.» (с)

Но, возможно, он уже решен =)

Сейчас набегут адепты постгресса и навтыкают мне, но все-таки, может вы не настроили MySQL нормально? Не представляю как оно может тормозить на таких объемах.
innodb_buffer_pool_size какой?

Хотя, если объем оперативы 1 гиг, и винт ноутбучный (5400), то какую базу не выбери — они будут за данными на винт бегать. А это не быстро.

[StrangeAttractor]

«может вы не настроили MySQL нормально? Не представляю как оно может тормозить на таких объемах.» — а оно и не тормозит, я просто интересуюсь, может есть более адекватная система для такой задачи. Гонять целый MySQL для одной простенькой таблицы, когда нет реляционной структуры кажется мне избыточным — наверняка есть что-то более заточенное под такую задачу. Ну и хранение БД в виде одного файла/каталога со стандартной для всех платформ структурой (одновременно с наличием нормальных библиотек-биндингов для разных языков и платформ) было бы ну очень приятным плюсом.

[StrangeAttractor]

Объём оперативы 4 гига, 1 GB — это то, что я не жалеючи могу полностью отдать процессу СУБД при том, что 2 GB у меня сожрёт сама прога (больше 32-битная JVM не позволяет), и мегов по 700 сожрут IntelliJ Idea и Firefox.

[sergeyfast]

У Vertica есть community edition, ограничения — 1 терабайт данных и масштабируемость максимум на 3 ноды.

Answer 4

[gelas]

По-моему, тут нет слысла менять СУБД.
Под описание SQL решение подходит практически идеально.
С document-based NoSQL наверняка получите больший объем на тех же данных, т.к. как там струкрура документа хранится в каждом документе.
Про colum-based NoSQL ничего не скажу, но хранить оптимальнее чем в SQL СУБД врядли получится.
Соответственно медленне может стать только из-за большего объема, плюс при отсутствии опыта могут вылазить непредвиденные проблемы.
Я думаю, лучшим вариантом будет просто правильно пооптимизировать существующее решение и разобраться с переносом, что вроде бы не особенно сложно, да и инструкции есть

Comments

[StrangeAttractor]

«разобраться с переносом, что вроде бы не особенно сложно, да и инструкции есть » — инструкция про MyISAM, не про InnoDB, а в одну MyISAM-таблицу вроде нельзя писать с нескольких процессов одновременно. При этом хочется избежать экспорта-импорта т.к. на таких объёмах это довольно долго. Хочется, скажем, отключить внешний винч с базой от Linux-ноута, воткнуть в виндовый десктоп и сразу работать. «Хотеть не вредно», конечно, но спросил об этом по тому, что показалось логичным, что существуют СУБД со стандартным (не зависимым от платформы) форматом хранения (наоборот даже удивило, когда впервые об этом задумался, что Linux и Windows версии MySQL на одном компе (с двойной загрузкой и общим NTFS-разделом) не могут просто использовать одни и те же файлы хранилища).

Answer 5

[Пума Тайланд]

1-10 миллионов записей фигня, хоть mysql, хоть mongo, хоть в файле храни правильно.
Количество данных ни о чем.