Первый вопрос: почему вы с самого начала работаете с реляционной базой данных, если вам не нужны свойства ACID? Похоже, вы выполняете некоторую нетранзакционную работу, поэтому получение RDMBS с транзакциями, вероятно, слишком сложно для вашей среды.
Второй вопрос: какие данные вы храните? Похоже, вам нужна база данных с хранилищем столбцов, и что она предназначена для какого-то проекта хранилища данных.
Третий вопрос: если вы застряли с PostgreSQL (которая является прекрасной базой данных как есть), то это текущая версия? Старые версии до 8.x, как известно, работают медленно, но много работы были усовершенствованы с тех пор, и некоторые из упомянутых вами проблем - например, автоочистка - теперь легко решаются с помощью настроек «установил и забыл».
* Data growing with snowball effect
Было бы неплохо получить дополнительную информацию об этом. Почему снежный ком? Можете ли вы нормализовать его, чтобы уменьшить объем памяти?
* existing postgresql locks table etc for vaccuum tasks periodically
Если это проблема, я уже могу сказать, что вы используете более старую версию. В более новых версиях для этого есть элементы управления для каждой таблицы, и вы даже можете полностью отключить его.
* Archiving data is tideous currently
Здесь сложно сделать какое-либо суждение, потому что работать не с чем. На какой носитель выгружается архив? Насколько задействован устойчивый ввод-вывод? В каких временных рамках вы работаете? Сколько данных? Это должна быть "горячая" свалка или может быть "холодная"?
* Human interaction involved in existing archive, vaccuum, ... process periodically
Я пытаюсь понять, насколько «нормальное» использование требует ручного вмешательства, потому что этого не должно быть. Вакуум теперь выполняется автоматически и (как упоминалось ранее) может быть отключен вообще, и большинство резервных копий создаются сценариями (а когда вы можете сценарий, вы можете запланировать). Так как же это происходит?
* Need a 'set it. forget it. just add another server when data grows more.' type of solution
Вы говорите о кластерном сервере.
Для меня это звучит так:
Кроме этого, здесь недостаточно информации, чтобы понять, что подойдет.
Вы также можете рассмотреть возможность изучения HBase и HyperTable; но опять же, как упомянул Эйвери Пейн, вы не предоставляете нам никакой информации о своем текущем приложении, а только о своей платформе базы данных.
О чем следует помнить:
На платформах, отличных от SQL, соединения выполняются вручную. Они не будут делать такие вещи, как внешние ключи, агрегаты и т. Д. Все это выполняется вручную.
Существующие приложения не всегда легко переносить. В зависимости от того, во что вам обойдется перенос, для вас может быть более рентабельным масштабирование сервера PostgreSQL по вертикали (а не по горизонтали).
Вы не получаете ACID, и вам нужно вручную управлять параллелизмом. В зависимости от вашего приложения это может быть проблемой. Вы также не можете обеспечить соблюдение глобальных правил сохранения традиционным способом, опять же из-за отсутствия атомарности.
Что вы можете сделать, чтобы решить некоторые из ваших проблем:
Таблица не заблокирована, она просто работает медленно. Это делается с помощью postgresql, чтобы предотвратить зацикливание идентификатора транзакции. Вы можете уменьшить частоту, записывая несколько строк партиями, а затем фиксируя. Вы можете использовать очередь (например, rabbitmq) для промежуточной записи: application-> queue-> db. Это также значительно увеличит вашу производительность записи.
Если ваши данные слишком велики, порядка нескольких ТБ, я бы посоветовал вам перейти в облако, потому что демпинг - это не вариант. Используйте AWS или Google Cloud и используйте снимки. Например. Моментальные снимки EBS, которые работают очень быстро, реплицируются на разных континентах и устраняют необходимость в резервном копировании.
Если под архивированием вы имеете в виду удаление данных и переход в «архив», то используйте табличные пространства, которые чередуются по дате. Для этого есть несколько реализаций в Интернете.
Кассандра - лучший вариант, когда вы знаете, что вам нужно масштабироваться.
Я бы порекомендовал некоторые статьи из тематических исследований от http://wiki.apache.org/cassandra/ArticlesAndPresentations