Проект по созданию системы управления реляционной базой данных
 

Язык C++. Платформы Windows/Linux Fedora 21. На других платформах не тестировалась.
Раньше был коммерческий проект, сейчас просто старания одного человека. Главная особенность базы в том что данные хранятся в оперативной памяти в виде индексов. Отсюда теоретически высокое быстродействие.
Готово ядро, часть парсера языка (работают запросы SELECT, UPDATE, DELETE, INSERT, отчасти CREATE DATABASE), имеется модуль для связи с клиентом по протоколу постгреса (в будущем планируется полная его поддержка. В идеале для клиента не должно быть никаких отличий). Работы еще много, хотя уже написано не мало.

Кто желает присоединиться, милости просим. Все на добровольных началах. Инвесторов пока нет.

Контакты: [email]mailfromslav@mail.ru[/email]

0-Slava_CPP > думаю проект не зря потерял коммерческую ценность, т.к. буквально 4-5 строчками кода в проекте и парой-тройкой строк в скриптах инициализации можно заставить MySQL/PostgreSQL работать в том же режиме. При этом MySQL/PostgreSQL являются уже проверенными продуктами со многими полезными фишками.

В связи с чем возникает вопрос - зачем нужен Ваш проект?

Я не хочу отговаривать Вас от проекта, более того есть желание помочь, но пока нет времени.

>т.к. буквально 4-5 строчками кода в проекте

вроде как постгрес индексы и так хранит в памяти если ее достаточно, другое дело если табличка в полтерабайта и половина из этого индексы...

2-wayerr > смотря какая табличка на полтерабайта. Можно выносить в индекс не всю таблицу, а ключевой столбец. Например при вводе можно обрабатывать "сложные" данные примерно так:
1. Получаем большой текстовый массив
2. В цикле обрабатываем слова, выписываем в индекс уникальные
3. Данные сохраняем на таблицу в харде, индексный (содержащий только список слов) пихаем в память. Как вариант - убираем ряд не значимых слов (например те которые есть во всех значениях, это будут предлоги и незначащие существительные). В зависимости от текста такой "условный индекс" может сократить объем данных в памяти от нескольких десятков до нескольких тысяч раз. А держать пару-тройку десятков гигов в ОЗУ на современных системах не проблема.
4. Выборку делаем двухэтапной - первичную по индексам, основную по полным значениям.

Хотя БД на полтерабайта (и по размеру и по важности) должна быть в кластере, а это уже совершенно другая тема.

>Можно выносить в индекс не всю таблицу, а ключевой столбец.

и что им потом делать, обмазываться?

>Хотя БД на полтерабайта (и по размеру и по важности) должна быть в кластере

зачем? постгрес эту табличку на хвосте вертит как угодно без особых тормозов

4-wayerr >
1. Доступ к данным (и выборка) в ОЗУ в 30 раз быстрее чем у HDD и в 5 раз быстрее чем на SSD. При грамотном распределении данных предварительная выборка из ключевого столбца с последующей окончательной получается быстрее "чистого" чтения с HDD.
2. Вылетевший винт приведет к скручиванию хвоста любого постгреса.

Важные данные в "боевой" системе по умолчанию должны дублироваться минимум 2 раза, а желательно 4 раза, при этом должны быть 2 серверные максимум удаленные друг от друга. Пожар, соседи сверху залили (если офис на 1 этаже), кондюк сдох и сервера перегрелись дофига короче в жизни бывает вариантов.

Вся соль этих систем в том, что шанс получить "мертвую" серверную 1/10000, но в эту единичку попасть может каждый. Случай был (не у меня, но это не важно) - крупная компания - серверная с парой сплит-систем (для резерва). Рядом (в 200-300 м) загорается магазин где много пластика, так вот через 20 минут после начала пожара хлопья сажи забили полностью наружные блоки сплитов. Сервачки (перегруженные кстати) бодренько уши в перегрев, работа организации из нескольких тысяч человек оказалась парализованной.

Другой случай - не повезло в сочетании 3-х факторов - дыра в окне, ветер в это окно и мышка которая провод погрызла. Итог - КЗ с вылетом (перегорели) все ИБП в серверной. 2 часа простоя.

Не нужно быть параноиками, но в нашей работе некоторая доля паранойи вещь необходимая, даже неотделимая.

>Доступ к данным (и выборка) в ОЗУ в 30

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

>Вылетевший винт

какой кошмар КО на марше

>. Пожар, соседи сверху залили

соседи датацентра определенно крутые парни, но к чему все это?

Ого. Стоило мне отлучиться на выходные, уже холивар развели тут. На самом деле постгрес обрабатывает запросы выборки медленнее чем тот же sqlite, хотя как база он гораздо лучше устроен. К тому же если у тебя база находится в своем процессе, она работает гораздо быстрее. Конечно конкурировать с постгресом и MySQL это глупо, но если рассматривать мою разработку как средство структурированного хранения и обработки данных, то думаю она будет полезна для широкого круга задач. Зачем делать свой контейнер для хранения данных, уже есть std::vector?
1isadmin > Вы не правы, когда говорили потерю коммерческой ценности. Были заинтересовавшиеся фирмы, но тогда проект представлял из себя очень сырой набор разрозненных библиотек. Нужно было время на доработку. Но обещать, не значит женится. Поэтому проект не приобрел заказчиков.
Резюмирую все это строкой с сайта sqlite:
Small. Fast. Reliable.Choose any three.

> холивар развели тут. На самом деле постгрес обрабатывает запросы выборки медленнее чем тот же sqlite

бгг, зачем же так толсто подбрасывать дров в этот холивар

6-wayerr > не ерничай. Я уже писал, что сжатый индекс может спокойно лечь в оперативу.
Спасибо что КО вспомнили, но почему бы его не вспомнить до написания 4-го поста?
99% компаний не используют дата-центры. Поэтому залитые серверные (комнаты в многоэтажках или офисных зданиях) хоть и большая редкость, но и уникальными явлениями такие события уже не назовешь.
7-Slava_CPP > ну если спрос есть (кому-то нужно), то можно будет и поучаствовать.
8-wayerr > да это еще не дрова, вот если затронуть процедуру выполнения запросов, то там такой холивар можно развести... MS vs. Linux отдыхать будет в сторонке...

9-1isadmin > уже писал, что сжатый индекс может спокойно лечь в оперативу.

250гб сжать в 100500 раз архиватором md5sum.exe , ага, продолжаем шутить?

>99% компаний не используют дата-центры.

100% статистики высосано из пальца

[quote=1isadmin;37995183] 7-Slava_CPP > ну если спрос есть (кому-то нужно), то можно будет и поучаствовать. [/quote] Да. Спрос был. В Новосибирске и Нижнем Новгороде заинтересовались тогда. Вообще 1С работает с постгрес. С нынешней политикой замещения иностранных программных продуктов отечественными можно было бы где-то залезть и к бюджетникам. Но я вижу лучшее применение как встроенная база данных в приложение. Как пример могу привести один проект, в котором я участвовал. Игра. Все свои данные хранились в xml файлах. И обращения к ним было дело не для слабонервных. Если тебе нужно было, например, локацию загрузить, тебе для начала необходимо было выбрать нужный xml файл в файловой системе, загрузить его, потому уже работать дальше. Вот если бы было какое-то решение как встроенная база данных, было бы гораздо лучше. А развертывать постгрес или мускуль для такой задачи это как стрелять по воробьям из пушки

[quote=wayerr;37997687] 9-1isadmin > уже писал, что сжатый индекс может спокойно лечь в оперативу.
250гб сжать в 100500 раз архиватором md5sum.exe , ага, продолжаем шутить?[/quote]

Ты прочитай что такое быстрая индексация. Я в 3-м посте даже описание алгоритма дал.

[quote=wayerr;37997687]>99% компаний не используют дата-центры.
100% статистики высосано из пальца [/quote]
В России зарегистрировано около 4 миллионов хозяйствующих субъектов (компаний), число дата-центров в России по состоянию на конец 2014 года - 175, число стоек составляет примерно 25,5 тысяч. Простое математическое действие показывает, что число компаний на ЦОД составляет примерно 1/23 тысячам, число компаний к стойкам 1/156. При этом как показывает аналитика большая часть ЦОДов находится у разных телекомов, а основными клиентами на стойки являются банки и научные организации. Частные клиенты в основном пользуются VDS.

Пруфлинк: [url]http://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%A6%D0%9E%D0%94_(%D1%80%D1%8B%D0%BD%D0%BE%D0%BA_%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D0%B8)_%D0%9A%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D0%B4%D0%B0%D1%82%D0%B0-%D1%86%D0%B5%D0%BD%D1%82%D1%80%D1%8B[/url]

Клоуна из себя не строй, или тебя на Яндексе и гугле забанили?

>Ты прочитай что такое быстрая индексация. Я в 3-м посте даже описание алгоритма дал.

в 3 посте ты написал свою курсовую, упомянутая таблица в полтерабайта забита данными с навигационных датчиков, какие там в задницу предлоги?

>В России зарегистрировано около 4 миллионов хозяйствующих субъектов (компаний), число дата-центров в России по состоянию на конец 2014 года - 175

ты щас будешь мне рассказывать что 99% (твоих любимых) фирм однодневок и ИП все юзают сервера? Да и щас я выйду на рынок там 100500 ИП и ООО и все имеют сайтики и нужнаются в дедиках.

>Клоуна из себя не строй

Цирк тут определенно устроил "специалист" который работал в полутора конторах и называет это "Аналитикой". Что характерно это номально среди студентов.

[quote=wayerr;38015681]в 3 посте ты написал свою курсовую, упомянутая таблица в полтерабайта забита данными с навигационных датчиков, какие там в задницу предлоги? [/quote]
Сравним число БД с навигационными данными и число БД со списками конрагентов и "историями" отношений с этими контрагентами? НавБД - очень нишевый продукт.

[quote=wayerr;38015681]ты щас будешь мне рассказывать что 99% (твоих любимых) фирм однодневок и ИП все юзают сервера? Да и щас я выйду на рынок там 100500 ИП и ООО и все имеют сайтики и нужнаются в дедиках.[/quote]
С учетом того что
[quote=wayerr;37988915]>. Пожар, соседи сверху залили соседи датацентра определенно крутые парни, но к чему все это? [/quote]
мы первоначально рассматривали вопрос хранения данных в офисе, а потом перескочили на "соседей сверху" ЦОДов...

Юзают сервера, не профессиональные конечно, но юзают. Те же сервера 1С и файлопомойки.

И кстати "все имеют сайтики" - огромное заблуждение, "сайтики" имеют менее 40% ИП и ООО.

[quote=wayerr;38015681]Цирк тут определенно устроил "специалист" который работал в полутора конторах и называет это "Аналитикой". Что характерно это номально среди студентов. [/quote] Студент, набери 12 лет практического опыта работы с малым и средним бизнесом, потом и поговорим.

>Ты прочитай что такое быстрая индексация. Я в 3-м посте даже описание алгоритма дал.

>Сравним число БД с навигационными данными и число БД со списками конрагентов и "историями" отношений с этими контрагентами?

Товарищь, вы хотябы записывайте то что говорите от поста к посту.

>И кстати "все имеют сайтики" - огромное заблуждение, "сайтики" имеют менее 40% ИП и ООО.

Это сарказм.

> набери 12 лет практического опыта работы с малым и средним бизнесом, потом и поговорим.

Значит работаешь со школы. И до сих пор рисуешь алогоримты индексации предлогов? Яб на твоем месте не писал про 12 лет, за такой срок можно узнать что существует постгрес и lucene, хотя если средний бизне требует чистить мышки

15-wayerr >
1. Я не записываю, а читаю посты выше.
2. Сарказм. Нет это показатель уровня ИП и ООО.
3. Не со школы. И не индексирую предлоги. Ты не на моем месте. Постгрес знаю, как и MySQL, SQLite и т.д. Есть задачи под каждую БД, особенно если отмоделировать работу каждой БД... Хотя о чем я... Человек который уперся рогом в одну БД не в состоянии осознать, что будь эта единственная БД идеальной остальные уже бы вымерли. Или ты считаешь, что профессионалы от нефиг делать учат 500+ листовые справочники по каждой БД? Наверное нечего читать на ночь... И на работе нечего делать кроме как программные продукты тестировать...

Кстати, правильно писать The Apache Lucene, т.к. понятие lucene охватывает только Java версию (не самую лучшую), хотя в вебе скорее будет использоваться Zend_Lucene, Kinosearch, Plucene а в высоконагруженных программах Lucene4c.

>1. Я не записываю, а читаю посты выше.

судя по результату это не помогает

> Сарказм. Нет

Это даже ненужно комментировать

>Не со школы. И не индексирую предлоги

>Данные сохраняем на таблицу в харде, индексный (содержащий только список слов) пихаем в память

Да, да, предлоги надо отбросить!

> Постгрес знаю, как и MySQL, SQLite и т.д.

Ну если размахивать своими знаниями то не упомянув три постыдные базы, что ж так мало то?

Эх... Надоел ты мне wayerr... Постыдные базы? Ну-ну... Учебники найди в яндексе или гугле, а потом приходи.