targeteКак лучше организовать хранение большого количества записей следующего типа?
datetime;byte;float

Необходимо обеспечивать непрерывную вставку около 2000 записей в 1-2 секунды.
Сервер базы должен запускаться на том же компе, что и приложение.
Запросы к таблице таких записей будут делаться очень редко, поэтому скорость для них особой роли не играет.
Записи хранить все не обязательно, т.е. с определенной периодичностью (день/неделя/месяц) база будет очищаться от большей части записей.
Что лучше использовать SQL, NoSQL или лучше вообще просто писать данные в файлы на хдд?

И еще дополнительный вопрос по размеру хранимых данных.
Насколько серьезна разница в размере базы, при хранении в ней int вместо float и при хранении smallint вместо int?
mumps - лучший выбор для такой задачи. Как, впрочем, и для любой другой:) Но здесь преимущества ее свойств, вероятно, очевидны даже для поклонников реляционной технологии.

АнатоЛойБредятинаmumps - лучший выбор для такой задачи. Как, впрочем, и для любой другой:) Но здесь преимущества ее свойств, вероятно, очевидны даже для поклонников реляционной технологии.
Бредятина...
Странное отношение к реляционным БД. Не ожидал, честно говоря)

Infernal V. RavenБредятина,

Ты еще FVMAS посоветуй...
Явное непонимание задачи, в частности, и технологий БД, в целом:)

Arhat109Бредятина... mumps - лучший выбор для такой задачи. Как, впрочем, и для любой другой:) Но здесь преимущества ее свойств, вероятно, очевидны даже для поклонников реляционной технологии.

Неплохая мысль. Вот решился на такую задачу http://www.sql.ru/forum/actualthread.aspx?tid=959510&pg=2 (последний пост)
, помогать будете?

На сегодня: есть исходники MySQL 5.5.27, mumps с сайта Кейна (кажется так зовут), куча инструкций "как добавить плагин к MySQL" ... и перерыв лет 15 в практике программирования на С, С++ .
Вы перескочили к другой задаче:
"Поэтому решил сделать авторазборщик товарных строк для всех страждущих.
... но понятно, что EAV = костыль к РСУБД (любой), хотя, в то же самое время, существуют и давно (с лохматых 1970-х) нормальные иерархические БД (тот же М), которые с такой задачей не просто справляются "на ура", но и специально созданы для её решения...

в итоге, появилась мысля полноценно прикрутить движок GT.M (mumps) к MySQL (бесплатен, и достаточно хорошо его знаю, надеюсь :) ... и уже на базе этого, делать "свой сайт"."
1) mumps - не иерархическая БД, и с лохматых 60-х, а не 70-х;
2) не имеет никакого отношения к EAV - то есть, не создавался специально для решения "такой задачи";
3) не понятно зачем прикручивать GT.M к MySQL - чем это отличается от "костыля к РСУБД"?
4) тем не менее, обращайтесь за помощью на соответствующий форум.
Но, повторюсь, к обсуждаемой задаче это никакого отношения не имеет.

АнатоЛойБредятинапропущено...
Странное отношение к реляционным БД. Не ожидал, честно говоря)
Мой комментарий стоит воспринимать так:
Интересное предисловие:) То есть, сам комментарий настолько непонятен?:)
АнатоЛой1. mumps - лучший выбор для такой задачи.
Без аргументов это "высокомерная бредятина".
Разумеется, технических аргументов у Вас никогда не было ни по одному вопросу:)
АнатоЛой2. Как, впрочем, и для любой другой:)
Без аргументов это "бредятина, поскольку полностью потеряна связь с реальностью".
Разумеется, технических аргументов у Вас нет, в то время, как я четко показал бесполезность SQL, и даже нашел и обосновал одну сферу применения алгебры, когда она не противоречит семантике и, безусловно, полезна:)
Это к задаче обсуждаемой не относится, но раз у Вас по обсуждаемой задаче аргументов нет, то полезно напомнить Вам некоторые факты, для общего развития:)
АнатоЛой3. "Но здесь преимущества ее свойств, вероятно, очевидны даже для поклонников реляционной технологии."
Это бредятина, вытекающая из уверенности, что все "поклонники реляционной технологии" точно знают о mumps и её реинкарнациях реализациях, а также разделяют точку зрения Бредятины о её свойствах для данной задачи.

То, что люди, считающие себя специалистами в области БД, не знакомы с технологиями БД, я согласен. Но не все, к счастью:) Слово "все" употребили Вы, а не я, так как по-существу Вам сказать нечего.
АнатоЛой4 "Бредятина..." = "Бредятина держит стиль"
Разумеется. Мой стиль помогает Вам развиваться:)

Arhat1092. ... Возможно неправ, но мне так кажется, что хранение разреженных медицинских данных, от хранения разношерстного набора товарных параметров - отличается мало. Для второго используется термин EAV (который пользовал с лохматых 80-х не зная о названии :)
Повторюсь, тема EAV здесь обсуждается постоянно и никакого отношения к обсуждаемому вопросу не имеет. Никакого. См., например:

http://www.sql.ru/forum/actualthread.aspx?tid=963382
http://www.sql.ru/forum/actualthread.aspx?tid=956140

Arhat109... насколько понимаю, mumps - все-таки система хранения разреженных сбалансированных деревьев (для чего и создавался, по крайней мере так прочел на сайте Кейна когда-то)
- чем это отличается от "иерархических БД"? Лично я не вижу разницы, акромя терминологической.
Неверно. mumps - это технология. Ориентирована, в первую очередь, на создание СУБД. Никакой модели данных, сама по себе, не поддерживает.
Arhat1093. Наверное затем, чтобы иметь возможность эффективно (а не костылем EAV) работать с такими структурами. Предлагать работать _полностью_ на GT.M (mumps, cache) - мне не надо. Мне хватило "пробного" использования. По самые помидоры.
Я Вам ничего не предлагаю. Только предостерегаю - поставленная Вами себе задача не корректна, и не стоит тратить на это время.
Arhat109"... от костыля к РСУБД..." - смотря как делать. Можно и расширение костылем назвать, только в печку совать не надо. :)
Расширение чего чем? Вы заблуждаетесь:)
Arhat109РСУБД - достаточно эффективно решают тот круг задач, в которых они используются, почему надо от этого отказываться?
Не надо. Только полезно знать, что реляционных СУБД просто не существует, а для оправданного применения алгебры мне известна только одна задача:) Вы, вероятно, имеете в виду коммерческий успех "реляционных систем", но меня коммерция совсем не интересует.
Arhat109Повторюсь: есть большое подозрение, что к обсуждаемой задаче - оно имеет самое прямое отношение. :)
Ваше подозрение напрасно:)
Arhat109Сразу: насколько Вы хорошо разбираетесь в исходном коде этого движка? У меня сложилось впечатление, что вполне допустимо заменить язык М на json формат... или я ещё не всё там нашел?
Я свое мнение о Вашей затее высказал:) Если все же будете этим заниматься, обращайтесь на форум по mumps

АнатоЛойНет, просто ваш комментарий на него меня озадачил. Решил уточнить :)
Мой комментарий был на Ваше оскорбление:) Я всегда так комментирую сообщения не по существу вопроса.
АнатоЛойНе опускаясь в технические детали: на этом уровне они излишни.
Уверен, что у Вас их нет:) На каком еще "этом уровне"?
АнатоЛойБыли отличные технические детали от V&N. Я же не агитировал за другие варианты, типа mumps :). Вот и обозначил - агитация, никаких аргументов.
Из этого следует только то, что с mumps Вы не знакомы. И Вам приходится использовать термин "агитация". Я здесь не собираюсь объяснять свойства mumps, так же, как и свойства "реляционных систем". Вам достаточно "отличных технических деталей" - это вполне нормально, могли бы обойтись без оскорбительных комментариев, не зная что такое mumps.
АнатоЛойЭто бесспорно. Надеюсь хоть в какой-то мере это взаимно :).
Конечно.

АнатоЛойБредятина, не уверен что должен, но всё-таки извиняюсь за употребление вашего ника "вслух" в гордом одиночестве в своём первом посте :) (если с вашей точки зрения "комментарий не по существу вопроса" приравнивается к оскорблению). Вы же сами этим ником провоцируете .
Вы хотите придумать мне другой ник?:) Когда я зарегистрировался под своими фамилией, именем и отчеством меня тут же заблокировали из-за обсуждения вопросов по существу:)
АнатоЛойНе отрицаю, даже скорее уместнее термин "слышал". Я поставил себя на место ТС. Если уж вернуться "по существу темы" - а что, ТС с ней "знаком"?
Не уверен, что знаком, но считаю, что это (незнакомство) недопустимо для специалистов в области БД.
[quot АнатоЛой]
Ну то есть: вместо "Cчитаю, что mumps -наилучший вариант <потому-то из двух предложений>" ваша фраза не агитация? (говорю как экономист-маркетолог в том числе :)./quot]
Я здесь (на sql.ru) объяснял много раз и свойства mumps, и свойства "реляционных систем" и другие вопросы теории БД. mumps нужно знать человеку, который всерьез занимается БД.

Arhat109Бредятина, спасибо. Эти ссылки я уже читал и даже те, которые даны (в том числе и Вами) внутри этих ссылок. Все.
, к сожалению, ничего кроме общей демагогии о том что mumps "единственная" технология, я там НЕ нашел. Может плохо смотрел.
Очень плохо смотрели, причем, я не сомневаюсь, что Вы это и сами знаете:) Как меня здесь только не называли:) Разумеется, я - демагог:)
Arhat109, также жаль, с Вашим опытом работы с mumps, ожидал услышать о какой-нибудь поддержке, но отсылка на форум (где обычно решаются вопросы по ИСПОЛЬЗОВАНИЮ продукта/технологии), при заявленной необходимости лезть в потроха продукта (переработки исходника под плагин) - лично мне указывает, что внутренностей mumps - Вы не знаете, несмотря на столь долгий срок общения с ним. Жаль, если так.
Я Вам не просто поддержку оказал, а дал рекомендацию в надежности которой Вы, рано или поздно, убедитесь - Вы хотите решить бесполезную задачу. Поэтому я, не просто демагог, а еще и не знаю внутренностей:) Разумеется:)

Arhat109Бредятина,
извиняюсь за резкий тон предыдущего сообщения. Но
, что Вы предлагаете (мне, ТС, многим другим смотрящим в сторону EAV) реально ВМЕСТО общих рассуждений о том, что GT.M(Cache, Free.M, MSM, etc.) "единственная верная технология"?
Сначала напомню, что мы говорим не по теме.
Вы опять невнимательно читали:( Я не использую таких выражений. как "единственная верная". И очень ясно аргументирую. Вероятно, Вам следует обсуждать вопросы, связанные с EAV в соответствующих темах.
Arhat109На основной работе у меня есть те же проблемы, что и у ТС, а именно работа с произвольными параметрами товарных позиций.
Тема НЕ ПРО ЭТО СОВЕРШЕННО!
Arhat109На сегодня, отдельных категорий товаров - 250, планируется увеличение (есть уже черновой список) до 60_000. Общее число товарных групп по всем категориям "на сегодня" - 50000, планируется рост до 2млн., каждая товарная группа (ожидается) будет иметь от 5 до 150 параметров (много пересекающихся)... сейчас пока до 8шт.
Что посоветуете, при условии работающего Мускуля?
Искренне - НИЧЕГО.
Ответьте для себя, например, на такой вопрос: чем меня не устраивает drupal? В котором, кстати, активно используется EAV:)

Arhat109_мод, нажал случайно Enter, дополню:
"EAV" - Дык! Об чем и речь, что "Бредятина" утверждает, что это неверная модель данных
Неправда. Не следует говорить неправду в такой простой жизненной ситуации:)
Arhat109, и ваще Мускуль не РСУБД...
РСУБД создать не удалось. MySQL не только не РСУБД, но даже не СУБД.
Arhat109вот и вопрошаю, КАК сделать так, чтобы работало то, что по его мнению "единственно верное решение"... желательно без переписывания всего того что есть...
Гарантирую - никак.
Arhat109... имхо: сделать плагин к Мускулю. И пусть то что есть, на Мускуле и крутится, а вместо костыля EAV, использовать то самое "верное" решение... говорит неверная постановка задачи... а КАКАЯ будет верная?
Чудо какое-то:) Вы данные как собираетесь хранить в MySQL? Какая схема данных, которая как крутится, так и будет крутиться?

Arhat109ППЦ! Я - дал ВАМ ссылку на свою тему, Вы решили обсуждать здесь, приведя цитаты из моей темы (оттудова!)... и теперь оказывается, что я же и виноват, не хилый бред!
Я не решил:) И Вы не виноваты. Эта тема не имеет ни малейшего отношения к EAV. Это просто факт:) И вместо того, чтобы злиться нужно было внимательно читать темы по Вашему вопросу. А Вы продолжаете игнорировать все объяснения, которые там содержатся. Конечно, можно предложить, что просто не понимаете, но у меня складывается впечатление, что именно сознательно игнорируете.
Arhat109Для данной задачи (этой темы), мой небольшой опыт как раз подсказывает, что mumps - совершенно НЕПОДХОДЯЩЕЕ решение.
Небольшой опыт довольно часто приводит к ошибочным выводам. Вы заблуждаетесь, и вряд ли сможете технически объяснить что именно подсказывает Вам небольшой опыт:) Поскольку mumps уже 40 лет успешно используется для этой задачи:)
Arhat109Если надо писать 2000 записей в секунду, то самым быстрым решением будет писание сблокированных записей (хоть через Memcached, хоть просто в массиве памяти) на диск. И это - самое быстрое решение, потому что самое простое.
Только для записи - ни БД, ни СУБД, ни РСУБД, ни mumps - НЕ НУЖЕН.
А вот если потом надо будет читать, да по условиям, то и надо смотреть КАК будут организованы чтения, какие условия выборки и требования к временным параметрам чтения... и опять тут mumps - не причем. Нет тут ни сложной организации данных, ни разреженных деревьев, ни программ как данных, по сути ничего нет. Простая табличка.
Очень хорошо! Автору темы будет полезно услышать Вашу точку зрения. Простая табличка:) Но по совокупности приведенных Вами двух половинок (запись - чтение) - mumps превосходит другие системы баз данных. Этот факт давно и хорошо известен:)
Arhat109По вашему ответу: никак. Во-от, правильно говорите, правильно. И для задач EAV "по большому счету" mumps - не подходит, потому как не индексируется нормально.
Вы себя-то не запутывайте:) Никак - потому что MySQL. Зря Вы игнорируете подробные объяснения про EAV в соответствующих темах. В том числе, про "не нормальное индексирование". Вот здесь я уверен, что Вы просто не знакомы с mumps. Совсем:)
Arhat109Собственно мой опыт и был как раз попыткой решить эту модель на технологиях mumps. Несколько лучше чем костыль EAV, но все равно "та же фигня, вид сбоку". потому как (имхо) истина, где-то посередине.
Я Вам предложил пути размышлений. Задал конкретные вопросы. Но Вы - не читатель, Вы - писатель. И опять клоните к бесперспективному решению - "mumps-плагин к MySQL". Суть EAV в хранении данных. Если Вы будете разрабатывать СУБД, ориентированную на модель EAV, то должны знать о технологиях разработки СУБД. Иначе, конечно, "костыли". Просто поищите наилучший "костыль EAV" для MySQL, раз Вы выбрали MySQL для организации своей БД.

Arhat109Бредятина, по теме EAV и по теме mumps, перечитал здесь достаточно много, в том числе и темы датированные 2002годом.
Во-первых, mumps - не самая быстрая СУБД, как бы Вам не хотелось, чего из означенных тем почерпнуть таки можно. И уж тем более в версии Cache. Хотя бы потому, что итоговая конечная скорость складывается из многих факторов, что неплохо продемонстрировано здесь же в темах.
Вы пока недостаточно разобрались, хотя и перечитали много:) mumps - не СУБД, и мне никак не могло хотеться того, о чем Вы пишите. Обратитесь на форум, где есть специалисты в области технологий БД, в целом, и mumps, в частности (важен союз "и":)). Cache - не версия mumps. ISM (вероятно Вы ее имели в виду) - была весьма быстрой "версией", как Вы выражаетесь, и всегда отличалась расширениями стандарта. По поднятому Вами вопросу не нужно много читать, нужно читать ответы на Ваши вопросы, которые есть в приведенных темах.
Arhat109Прямой доступ к данным через B-деревья, безусловно быстрая технология, но она есть даже в Мускуле. Реализовать прямую обработку данных с прямой индексной выборкой через уже имеющийся(!) плагин я могу тоже. И без выкрутасов на идиотском жаргоне Васика - "М". На нормальном С/С++. Компилируемом.
"Доступ к данным через B-деревья" - такой жаргон говорит лишь о недостаточном понимании технологии БД. Вы "можете реализовать прямую обработку данных с прямой индексной выборкой на нормальном С" - это же великолепно! Причем, данных, хранимых в MySQL в виде структур EAV. Просто замечательно! Что за проблемы Вы себе придумали ранее не вполне понятно:)
Arhat109Во-вторых, к решению задачи, озвученной ТС mumps явно не подходит, хотя бы потому, что в нем "ВСЁ СУТЬ СТРОКА"... хранить float в строке конечно можно, и наверное с наукопознавательными целями полезно, но искать быстро трудно...
Полное непонимание предмета и технологий программирования, в том числе. Напомню, что C изначально был языком без типов. Это огромное преимущество, между прочим:)
Arhat109В третьих, наукообразное теоретизирование меня не интересует.
Но Вы только им и занимаетесь:) Уточню - технологии БД Вас не интересуют. Вам бы плагины попрограммировать. Причем, зачем-то с использованием "медленной и идиотской" технологии:) Успехов, тем не менее:)

Arhat109Как писатель, добавлю для тех кто любит слышать только себя:
вот слова ТС:
...
Вы уже сами с собой начали разговаривать?:)
Arhat109Так вот, поскольку скорость выборки НЕ важна (читайте первый пост), запись быстрее чем в файл не сделает даже перехваленный mumps (тоже пишет в файл через ФС плюс накладняк), а уж размер хранения float в строковом виде превышает любой обсуждаемый размер (основной вопрос для ТС!), то mumps - не подходит .
Надеюсь, такое техническое обоснование - понятно, или "не по науке"?
Такое техническое обоснование говорит только о полном не знании mumps. Больше оно ни о чем не говорит. Вы сделали главным размер? Очень хорошо! Приведите размер БД в mumps и в любой другой БД. Я подчеркиваю - БД. Если Вы предлагаете БД не использовать (в этой сфере - "не БД" - как раз _мод специалист), то здесь я с Вами не поспорю, конечно. Я про "не БД" мало знаю:)

Arhat109Вот как раз ТАКИЕ Ваши ответы (и их тут полно и не только мне!) Я и называю демагогией. Далее пожалуйста, занимайтесь этим без моего участия. Ок?
Я и не сомневался, что Вам нечего сказать по существу из-за незнания технологий БД. Но не расстраивайтесь, у Вас еще все впереди. Причем, я уверен, что Вы только на словах игнорируете конкретные объяснения и советы, делая вид, что они Вам не понятны. Здесь многие имеют такую странную привычку:) А на самом деле, наверняка, многое поняли. И теперь Ваши заработки станут просто запредельными:)

Arhat109Бредятина, ровно настолько насколько нежно отношусь к фантазерам и теоретикам, настолько же тяжело реагирую на телепатов, которые любят делать выводы за счет своих способностей. Поэтому, не обижатесь на резкие выпады с моей стороны. У меня к Вам двойственное впечатление. Оставьте свои выводы об уровне моих знаний при себе. Мне - глубоко все-равно, что Вы на эту тему думаете.
Как говорил один мой коллега: "не пугайте меня клавиатурой! Я программировал когда их ещё не было".
Не оставлю, дружище:) Мне истина дороже.
1) Вы сказали про размер? Для данной конкретной задачи какой размер БД (предположим на 1 млн. записей) будет в mumps и других БД?
2) Вы проигнорировали drupal.
3) Вы не поняли, что mumps-плагин к MySQL - нелепая затея? А если поняли, почему не сказали?
4) Вы не ответили как храните данные в MySQL.
И у меня, вполне естественно, сложилось мнение о Ваших знаниях. Я бы оставил его при себе, если бы Вы оставляли при себе "демагогию":) Четыре (примерно из 12-ти) пунктов выше - это не демагогия:) А я с некоторых пор (здесь!) отвечаю адекватно. Вам может и все равно, а мне Ваши знания небезразличны, и я и дальше буду их повышать:) Стыдно не знать mumps, если занимаетесь БД. У меня тоже есть пробел, и мне тоже стыдно - плохо знаком с COBOL. Вот надо восполнять:)

Arhat109Бредятина,
1. про "размер" ТС указал весьма недвусмысленно, что Вам ещё "не понятно"?

Не хитрите:) Люди же смотрят:) Мне-то все понятно. Вы сделали главным размер. Вы сказали, что mumps не подойдет из-за размера:) Не хотите отвечать на вопрос - не отвечайте. Просто разберитесь на досуге.
Arhat1092. я много чего проигнорировал, в том числе и фортран, алгол, кобол... про ассемблер - ваще молчу.

Опять хамите, дружище. Вы задумали делать сайт. Используете MySQL. При чем здесь фортран??? Чем Вас не устроил drupal, вот в чем вопрос:)
Arhat1093. нет. Я нашел его реализацию практически "в готовом виде". По крайней мере меня это устроило.

Отлично! Уже второй раз Вы говорите, что Вас все устраивает.
Arhat1094. есть данные в MyISAM (критичные к скорости выборок), остальное в InnoDb. так пойдет?

Нет, не пойдет. Нужна схема данных, чтобы Вы поняли где у Вас именно EAV - в данных или в коде:)
Arhat109стыдно не не знать mumps или какую ещё бредятину, стыдно заниматься демагогией в Вашем возрасте.

Дурачок:)
Arhat109"нельзя объять необъятное" (с) Козьма Прутков (1889г. если память не изменяет).
Глупости могли бы и не говорить так часто:) При чем здесь сев озимых или воспитание детей дошкольного возраста??? Какое необъятное??? Если Вы не знаете mumps, Вы не можете понимать основы БД. Потому что именно эта технология либо реализует, либо позволяет максимально эффективно реализовать все основные принципы БД, о чем я здесь много раз доходчиво писал:)

Arhat109: "вопрос снят. Нашел всё уже готовое, нифига делать не надо. Подниму тему, как сделаю сайт."
Наконец-то! Поздравляю!