Java DB выбрать для лучшей производительности - PullRequest
2 голосов
/ 09 декабря 2010

У меня есть Java-приложение, которое обрабатывает такие данные:

class MyData
{
     Date date;
     double one;
     double two;
     String comment;
}

Все данные хранятся в формате csv на жестком диске, максимальный размер такой последовательности данных составляет ~ 150 МБ, и на данный момент я просто полностью загружаю их в память и работаю с ними.

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

Мои вопросы:

  1. Какую БД лучше выбрать для моей причины (будет только 1 таблица с данными как выше)?
  2. Какая библиотека лучше использовать для подключения Java <-> DB
  3. Полагаю, что-то будет использовано как курсор?!? если так, есть ли реализация курсора с хорошей записью кэширование для быстрого доступа?

Любые другие советы и рекомендации по java <-> DB приветствуются!

Ответы [ 5 ]

5 голосов
/ 09 декабря 2010

Ваш вопрос довольно неопределенный.Нет лучшего в своем роде - это зависит от того, сколько у вас денег и какое оборудование.

Поскольку ваше отображение между Java и БД довольно простое, JDBC должно быть достаточно.JDBC создаст для вас курсор по мере необходимости;потерянный цикл по строкам в ResultSet.В зависимости от базы данных вам может понадобиться настроить ее на использование курсоров.

Поскольку вы упоминаете «сотни гигабайт», это исключает большинство «простых» баз данных.Если у вас есть деньги, попробуйте Oracle.Если у вас нет денег, попробуйте MySQL или Postgres.

Вы также можете попробовать JavaDB (также известный как Derby).Но я не уверен, что производительность будет именно тем, что вам нужно.

Обратите внимание, что у них у всех есть свои причуды и "особенности", поэтому вы должны потратить пару недель, чтобы найти свой путь к ним.

2 голосов
/ 09 декабря 2010

Полностью зависит от того, что вы будете делать с данными.Нужно ли индексировать его для извлечения определенных записей, или вы обрабатываете весь поток данных для создания некоторой статистики (например)?Требуется ли одновременный доступ к базе данных несколькими клиентами / процессами?

Не торопитесь сразу к SQL / JDBC, реляционные базы данных мощные, но они добавляют много сложности и часто совершенно не нужны для выполнения задачи.под рукой.

Опять же, в зависимости от того, что вам действительно нужно сделать, что-то вроде BerkeleyDB может удовлетворить все требования, или вам может просто понадобиться более компактный двоичный формат сообщения: проверьте Буферы протокола и Kryo .

Если вам действительно нужно увеличить масштаб, посмотрите на Hadoop / HDFS для распределенной обработки (но это становится довольно сложным).

Да, и вообще говоря, JavaDB / Derby имеет тенденцию несколько сосать.

1 голос
/ 09 декабря 2010

Вы захотите оценить несколько баз данных (вы можете получить пробные версии практически любой из них, если они еще не являются открытыми / бесплатными).Я бы порекомендовал попробовать Oracle, Mysql / Postgres и с размером ваших данных (и отсутствием очевидной сложности), возможно, вы захотите рассмотреть и сетку данных (gridgain или аналогичную).

Определенно прототип, хотя.

1 голос
/ 09 декабря 2010

Я бы порекомендовал JavaDB .Я использовал его в системе торговых точек, и она работает очень хорошо.Его очень легко интегрировать в приложение Java, и вы можете интегрировать его в тот же файл .jar, если хотите.

Использование Java DB в настольных приложениях может быть полезной статьей,Вы будете использовать JDBC для сопряжения базы данных с Java, это упрощает переключение на другую базу данных, если вы не хотите использовать JavaDB.

0 голосов
/ 09 декабря 2010

Я просто хотел бы добавить, что «самая быстрая» база данных не обязательно является лучшей.

Вам также необходимо учитывать:

  • надежность,
  • стоимость лицензии на ПО,
  • простота использования,
  • простота администрирования,
  • доступность поддержки,
  • и т. Д.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...