Максим Павлючук

93 млн. - сама по себе смешная нагрузка для современных СУБД на современных компьютерах.
Выбор СУБД зависит от того - а что именно вы собираетесь с этой базой данных делать.- в вопросе это не указано.

Ну например, если ваша цель быстро искать в это БД товары, а ваши 30 колонок - это фильтры, то отлично подходит СУБД для именно что полнотекстового поиска (пусть вас не смущает название, для фасеточного поиска она тоже подходит отлично). Это, к примеру:

• если вы ориентированы на скорость SphinxSearch
  
• если вам нужен кластер, то это ElasticSearch
  
• если вам нужны традиционные инструменты типа SQL, - то это PostgreSQL, MySQL.
  

Если же задача другая - то идеальным выбором может быть и другая СУБД.
Нужны детали.

Думаю, дело в том, что вы увидели эти 90 млн. и решили, что нужно какое-то специфичное решение и не стали даже уточнять детали - а на деле, ничего такого в этих 90 млн. нет. А вот детали задачи - важны.

Рассмотрим задачу быстрой перезаписи - вы имели ввиду все 90 млн. перезаписывать целиком? Не частично. А вот это будет действительно проблемой. Мало какая из СУБД способна на быстрые изменения такого объема.

Ну и третий раз повангую - максимально быстрый доступ к данным - это если данные размещены в оперативной памяти. Один из наиболее развитых инструментов, с размещение в оперативной памяти и с функционалом СУБД - Tarantool. Быстрее, чем in-memory DB, к которым относится Tarantool - и вариантов нет.

Но понадобится соответствующее количество оперативки.

Если оперативки мало, то можно глянуть Aerospike. Это "почти in-memory DB". Но объемы данных могут быть огромны, при небольших запросах к оперативке. От оперативки требуется только целиком вмещать индексы, а не сами данные.

Короче, ванговать мне надоело.

У вас нет постановки задачи - ответить вам посему и нечего конкретного невозможно.

Имеется команда:
ls -l -a && less build.sh
Команда - стоит на первом месте
Значение команды идет сразу после команды (если оно есть)
Опции - идут с префиксом '-' или '--', следуют за командой

Для bash не имеет значения, опции ли это и с чего они начинаются. bash рассматривает их просто как слова, которые он после неких трансформаций (таких как brace expansion, tilde expansion, parameter and variable expansion, command substitution, arithmetic expansion, word splitting и pathname expansion) передаёт как параметры запускаемой команде.

Требуется построить древо вызова... Сейчас имеется алгоритм который сплитами и циклами строит подобное дерево. Суть вопроса, какие подводные камни могут встретиться?

Зависит от того, каким должно быть это дерево вызова и какой объём возможного синтаксиса требуется поддерживать. Подводных камней -- масса, начать можно с кавычек в параметрах.

Существует ли документ, показывающий иерархию (приоритет) выполнения комманд, как, например, в java ?

man 1 bash