LINUX.ORG.RU

Какую СУБД выбрать для хранения на usb-хранителе

 , ,


0

1

Доброе...

Нужно «опортабелить» СУБД) То есть, все хранить на переносном хранителе, предположительно флешке ну или диске переносном.

Примерная нагрузка в день (примерно разово): от 200 до 1000 строк(запросов), это insert, update, так же select и сортировка

Разово - имею ввиду вот что: операции/запросы выполняются в течении одного часа.

Сразу оговорюсь - Сервер не предлагать, это есть, нужно именно портабельное решение.

Что предполагаю: это либо MySQL (например в сборке XAMPP) или SQLite.

Бекап планируется делать сразу по окончанию выполнения последнего запроса. Бекап на другой носитель.

Видимые проблемы:

  1. Это убиваемость флешки, как долго сможет флешка проработать под нагрузкой и считается ли это нагрузкой?)
  2. Нагрузка на Процессор/Память ПК, на котором будет запущен зверь) на сколько она может быть увеличена.
  3. Со временем, количество строк вырастет до 500000 - если брать SQLite - это же будет огромный файл и начнутся проблемы?

Что выбрать или может есть другие СУБД, которые могут помочь в данном вопросе.

Клиентская часть будет либо на php, либо на python'e.

Конечно, флешки проигрывают по надежности дискам переносным, поэтому это не окончательное решение.

Спасибо за советы - заранее)

дискам переносным

надежности

anonymous
()
Ответ на: комментарий от firefedot

Это типа hint такой для арказма

anonymous
()

оракл же, нахер полумеры.

anonymous
()

Нагрузка на Процессор/Память ПК
Клиентская часть будет либо на php, либо на python'e.

/0

Что мешает попробовать оба варианта и написать тут результаты?

anonymous
()

Странные у вас требования.

Если предполагается, что база должна быть постоянно on-line, то зачем выбирать заведомо ненадежный носитель информации? Первым делом нагрузка будет на дисковые операции, и производительность будет проседать именно в этом месте, а увеличить вы её не сможете.

База SQLite может расти до 140ТБ, но она вам не подойдет, т.к. если я не ошибаюсь она не многопользовательская, и в один момент времени записывать может только один, остальные только читать. Поэтому советую пересмотреть решение. Либо как уже рекомендовали firebird, есть ещё OpenOffice Base, Access и вариации dBase.

ThePretender
()
Ответ на: комментарий от ThePretender

На данный момент - она однопользовательская.

Мне нужно просто прикинуть частоту обращений к носителю,что бы знать примерно его время жизни.

Или подобрать носитель, но с максимальным показателем перезаписи.

firebird - посмотрю, про него и не подумал вообще

firefedot
() автор топика
Ответ на: комментарий от anonymous

Написать ни что не мешает, это больше для доп.информации, интересует больше нагрузка на флешку

firefedot
() автор топика

Сразу оговорюсь - Сервер не предлагать, это есть, нужно именно портабельное решение.

запускай сервер сам, например postgres -D /media/myusb/DbDir
поработал, останови

x905 ★★★★★
()
Ответ на: комментарий от x905

так понимаю, что сам postgres или другая СУБД - должна стоять на ПК?

а если именно установка не должна быть? и все с флешки/носителя стартует?

firefedot
() автор топика
Ответ на: комментарий от stevejobs

почему о нем не стоит забывать? какие киллер-фичи?

достаточное число «фич» http://www.sql-workbench.net/dbms_comparison.html и при этом может работать без сервера - как встроенная база.

кстати его полюбливают наши финансисты. Спонсор - Московская биржа.

MKuznetsov ★★★★★
()
Ответ на: комментарий от firefedot

так понимаю, что сам postgres или другая СУБД - должна стоять на ПК?

БД без установочных файлов это просто файл - например универсальный: текстовый. Если сортировка не нужна - то сойдет.

Обособленный файл в любом случае требует установочного ПО.

С автономным приложением сложнее. Можно что-то скриптовое, работающее через системное ПО. Например python, erlang

Носитель на флэшке с т.з. системы - абстракция, так что неважно где и на чем носитель.

Посмотрите в сторону доступа к БД через браузер - это есть на каждом ПК

anonymous
()
Ответ на: комментарий от MKuznetsov

есть ещё firebird, про который тут все забывают :-)

Потому что он говно.

AnDoR ★★★★★
()
Ответ на: комментарий от firefedot

так понимаю, что сам postgres или другая СУБД - должна стоять на ПК?

можно собрать самому postgres и поместить его на флешку

x905 ★★★★★
()

Со временем, количество строк вырастет до 500000 - если брать SQLite - это же будет огромный файл и начнутся проблемы?

У меня база в которой одна из табличек была примерно пол ляма занимала 200 мегов. Но если брать все таблички то там ~700тыс. строк было. Но в базе была исключительно текстовая инфа, всесьма скромных объемов.

Noob_Linux ★★★★
()
Последнее исправление: Noob_Linux (всего исправлений: 1)

Строго говоря думаю можно проблему решить так.

Пишем прогу которая будет выступать клиетской частью в таком виде: При запуске копирует файл базы во временную папку на компе(возможно даже в RAM, хотя это не очень безопасно) и уже работает там, по закрытию соответственно делает обратное действие. Думаю это сильно решит вопрос долговечности носителя. Хотя и отразиться на скорости запуска и завершения.

Noob_Linux ★★★★
()

Со временем, количество строк вырастет до 500000 - если брать SQLite - это же будет огромный файл и начнутся проблемы?

Сейчас посмотрел - у меня >1500000 жирнющих записей, БД занимает 3 гига и каких-то проблем не наблюдаю на селектах\инсертах (но БД, правда, живет на харде). Так что я бы выбрал sqlite, тем более что как-таковой сервер не будет нужен. А про однопользовательность - тут надо смотреть как у тебя приложение будет в нее писать, может ты этого и не заметишь.

alozovskoy ★★★★★
()
Последнее исправление: alozovskoy (всего исправлений: 1)
Ответ на: комментарий от alozovskoy

Да, пока про sqlite думаю... 1500000 строк в 3 гига, это не много .. тут меня спокойнее)

firefedot
() автор топика
Ответ на: комментарий от Noob_Linux

была такая мысль, про скидывание, но я только про Память думал, там безопасность сводиться только к резкому отключению питания, так то все так же будет ...

firefedot
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.