реализация высокопроизводительной распределенной файловой системы / базы данных

Question

Мне нужно реализовать максимально быстрый способ хранения пары ключ / значение в распределенной системе в Linux. Записи базы данных крошечные, в среднем 256 байт.

Я думаю использовать системные вызовы open (), write () и read () и записывать пары ключ-значение непосредственно с некоторым смещением в файле. Я могу опустить системный вызов fdatasync (), так как я буду использовать SSD-диск с батареей, поэтому мне не нужно беспокоиться о соответствии ACID, если произойдет неожиданное отключение системы. Linux уже обеспечивает реализацию дискового кэша, поэтому чтение / запись не будет происходить в секторах, которые уже были загружены в память. Это (я думаю) было бы самым быстрым способом хранения данных, намного быстрее, чем любой другой механизм базы данных с поддержкой кэширования, такой как, например, GT.M или Intersystem Globals.

Однако данные не реплицируются, и для достижения репликации я могу смонтировать файловую систему другого сервера Linux с NFS и скопировать туда данные, например, если у меня есть 2 сервера данных (1 локальный и 1 удаленный), Я бы выполнил 2 вызова open (), 2 write () и 2 close (). Если транзакция завершается неудачно на удаленном сервере, я отмечаю ее как «несинхронизированную» и просто копирую хороший файл снова, когда удаленный сервер возвращается.

Что вы думаете об этом подходе? Это будет быстро? Я могу использовать NFS поверх UDP, чтобы избежать накладных расходов на стек TCP.

Список преимуществ пока выглядит так:

• Повторное использование дискового кэша Linux
• Несколько строк кода
• Высокая производительность

Я буду кодировать это на C. Чтобы найти запись в файле, я буду хранить btree в памяти с указателем на физическое местоположение.

Answer 1

На ум приходят несколько предложений.

• необходимо ли открывать () / писать () / закрывать () для каждой транзакции? издержки системного вызова open () в частности, вероятно, нетривиальны

• не могли бы вы использовать mmap () вместо явных операций write ()?

• если вы делаете 2 вызова write () (1 локальный, 1 NFS) для каждой транзакции, кажется, что любой тип проблем в сети (задержка, отброшенные пакеты и т. Д.) Может привести к приложение до полной остановки, если вы ожидаете успешного вызова NFS write (). И если вы не ждете, например, выполняя запись NFS из отдельного потока, ваша сложность будет быстро расти (я не думаю, что «Несколько строк кода» останутся верными).

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

Answer 2

Вы можете изучить реальную распределенную файловую систему, а не использовать NFS, которая, как вы указываете, по-прежнему обеспечивает единую точку отказа и не реплицирует.

Файловая система Andrew (AFS), изначально разработанная CMU, может быть решением для вас. Это коммерческий продукт, но вы можете проверить OpenAFS , который работает на Linux (и других системах).

Предупреждение: AFS имеет кривую обучения.