|
|
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
Как лучше организовать хранение большого количества записей следующего типа? datetime;byte;float Необходимо обеспечивать непрерывную вставку около 2000 записей в 1-2 секунды. Сервер базы должен запускаться на том же компе, что и приложение. Запросы к таблице таких записей будут делаться очень редко, поэтому скорость для них особой роли не играет. Записи хранить все не обязательно, т.е. с определенной периодичностью (день/неделя/месяц) база будет очищаться от большей части записей. Что лучше использовать SQL, NoSQL или лучше вообще просто писать данные в файлы на хдд? И еще дополнительный вопрос по размеру хранимых данных. Насколько серьезна разница в размере базы, при хранении в ней int вместо float и при хранении smallint вместо int? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2012, 19:01 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
targeteЧто лучше использовать SQL, NoSQL или лучше вообще просто писать данные в файлы на хдд? Раз не будешь делать запросы, а только вставлять и удалять - пиши сразу в /dev/null Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2012, 19:41 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, пожалуй ваш ответ заслуживает того же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2012, 19:44 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
targeteЧто лучше использовать SQL, NoSQL или лучше вообще просто писать данные в файлы на хдд?Это как раз зависит от того, как нужно выбирать данные. targeteНасколько серьезна разница в размере базы, при хранении в ней int вместо float и при хранении smallint вместо int?Размер легко подсчитать, для этого нужно знать структуру таблицы и количество записей. Очевидно, " при хранении в ней int вместо float и при хранении smallint вместо int" место уменьшается в 2 раза, но в таблице ещё могут быть другие поля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2012, 19:57 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
alexeyvgв таблице ещё могут быть другие поля. Поля - фигня, выравнивание - вот забавный вопрос. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2012, 20:08 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
alexeyvg, стурктуру таблицы я выше указал. Повторю: datetime; byte; float ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2012, 20:09 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
alexeyvg, выборки нужны только по времени, от одной даты до другой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2012, 20:12 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
targetealexeyvg, стурктуру таблицы я выше указал. Повторю: datetime; byte; floatНу, если больше полей нет, индексов нет, ничего нет... datetime; byte; float = 8+1+8 = 17 байт datetime; byte; int = 8+1+4 = 13 байт datetime; byte; smallint = 8+1+2 = 11 байт БД имеют страничную организацию, соответственно будет потеря на заголовок страниц и на систему организации страничных структур, это обычно небольшая потеря, процента 2-3 И обычно есть процент заполнения, пустое место на странице, нужно для ускорения вставок данных в определённых ситуациях. Это регулируется, пожно сделать 50%, можно 0 Итого разница в размере базы будет примерно 6/17 или 4/17, то есть 23-35% Dimitry Sibiryakovalexeyvgв таблице ещё могут быть другие поля. Поля - фигня, выравнивание - вот забавный вопрос.А что это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2012, 21:08 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
targetealexeyvg, выборки нужны только по времени, от одной даты до другой.По датам? Нужно копить данные, а потом выдать все данные за требуемые сутки в виде файла? Тогда понятно лучьше хранить в файлах по суткам. С именами в виде даты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2012, 21:10 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2012, 23:52 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
> Как лучше организовать хранение большого количества записей следующего типа? > datetime;byte;float > Как ни странно, в виде таблицы. > И еще дополнительный вопрос по размеру хранимых данных. > Насколько серьезна разница в размере базы, при хранении в ней int вместо float и > при хранении smallint вместо int? int -- 4 или 8 байт (скорее всего 8). float если поддерживается твоей БД, то это 8 байт. Но часто не поддерживается и хранится как BCD или что-то в этом роде. тогда по кол-ву знаков. Я не думаю что при твоих объёмах нужно об этом думать. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2012, 12:55 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
On 08/29/2012 08:44 PM, targete wrote: > Dimitry Sibiryakov, пожалуй ваш ответ заслуживает того же. Почему же ? Правильный ответ, Дмитрий зрит в корень. Если тебе не нужно обрабатывать данные, то нафига их хранить ? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2012, 12:56 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
MasterZivOn 08/29/2012 08:44 PM, targete wrote: > Dimitry Sibiryakov, пожалуй ваш ответ заслуживает того же. Почему же ? Правильный ответ, Дмитрий зрит в корень. Если тебе не нужно обрабатывать данные, то нафига их хранить ? Dimitry Sibiryakov передёрнул смысл задачи от ТС. ТС: "Запросы к таблице таких записей будут делаться очень редко, поэтому скорость для них особой роли не играет." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2012, 14:00 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
targeteКак лучше организовать хранение большого количества записей следующего типа? datetime;byte;float Необходимо обеспечивать непрерывную вставку около 2000 записей в 1-2 секунды. Сервер базы должен запускаться на том же компе, что и приложение. Запросы к таблице таких записей будут делаться очень редко, поэтому скорость для них особой роли не играет. Записи хранить все не обязательно, т.е. с определенной периодичностью (день/неделя/месяц) база будет очищаться от большей части записей. Что лучше использовать SQL, NoSQL или лучше вообще просто писать данные в файлы на хдд? И еще дополнительный вопрос по размеру хранимых данных. Насколько серьезна разница в размере базы, при хранении в ней int вместо float и при хранении smallint вместо int? mumps - лучший выбор для такой задачи. Как, впрочем, и для любой другой:) Но здесь преимущества ее свойств, вероятно, очевидны даже для поклонников реляционной технологии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2012, 17:59 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
Бредятинаmumps - лучший выбор для такой задачи. Как, впрочем, и для любой другой:) Но здесь преимущества ее свойств, вероятно, очевидны даже для поклонников реляционной технологии. Бредятина... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2012, 18:09 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
Бредятина, Ты еще FVMAS посоветуй... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2012, 12:30 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
АнатоЛойБредятинаmumps - лучший выбор для такой задачи. Как, впрочем, и для любой другой:) Но здесь преимущества ее свойств, вероятно, очевидны даже для поклонников реляционной технологии. Бредятина... Странное отношение к реляционным БД. Не ожидал, честно говоря) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2012, 22:06 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
Infernal V. RavenБредятина, Ты еще FVMAS посоветуй... Явное непонимание задачи, в частности, и технологий БД, в целом:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2012, 22:07 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
Бредятина... mumps - лучший выбор для такой задачи. Как, впрочем, и для любой другой:) Но здесь преимущества ее свойств, вероятно, очевидны даже для поклонников реляционной технологии. Неплохая мысль. Вот решился на такую задачу http://www.sql.ru/forum/actualthread.aspx?tid=959510&pg=2 (последний пост) , помогать будете? На сегодня: есть исходники MySQL 5.5.27, mumps с сайта Кейна (кажется так зовут), куча инструкций "как добавить плагин к MySQL" ... и перерыв лет 15 в практике программирования на С, С++ . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2012, 06:12 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
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) тем не менее, обращайтесь за помощью на соответствующий форум. Но, повторюсь, к обсуждаемой задаче это никакого отношения не имеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2012, 11:17 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
БредятинаАнатоЛойпропущено... Бредятина... Странное отношение к реляционным БД. Не ожидал, честно говоря) Мой комментарий стоит воспринимать так: 1. mumps - лучший выбор для такой задачи. Без аргументов это "высокомерная бредятина". 2. Как, впрочем, и для любой другой:) Без аргументов это "бредятина, поскольку полностью потеряна связь с реальностью". 3. "Но здесь преимущества ее свойств, вероятно, очевидны даже для поклонников реляционной технологии." Это бредятина, вытекающая из уверенности, что все "поклонники реляционной технологии" точно знают о mumps и её реинкарнациях реализациях, а также разделяют точку зрения Бредятины о её свойствах для данной задачи. 4 "Бредятина..." = "Бредятина держит стиль" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2012, 11:47 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
Бредятина1) mumps - не иерархическая БД, и с лохматых 60-х, а не 70-х; 2) не имеет никакого отношения к EAV - то есть, не создавался специально для решения "такой задачи"; 3) не понятно зачем прикручивать GT.M к MySQL - чем это отличается от "костыля к РСУБД"? 4) тем не менее, обращайтесь за помощью на соответствующий форум. Но, повторюсь, к обсуждаемой задаче это никакого отношения не имеет. 1. Вам - виднее, мне - не суть важно. 2. У меня нет большого полноценного опыта работы с mumps (как понимаю у Вас оно есть). Только "пробное". Возможно неправ, но мне так кажется, что хранение разреженных медицинских данных, от хранения разношерстного набора товарных параметров - отличается мало. Для второго используется термин EAV (который пользовал с лохматых 80-х не зная о названии :) ... насколько понимаю, mumps - все-таки система хранения разреженных сбалансированных деревьев (для чего и создавался, по крайней мере так прочел на сайте Кейна когда-то) - чем это отличается от "иерархических БД"? Лично я не вижу разницы, акромя терминологической. 3. Наверное затем, чтобы иметь возможность эффективно (а не костылем EAV) работать с такими структурами. Предлагать работать _полностью_ на GT.M (mumps, cache) - мне не надо. Мне хватило "пробного" использования. По самые помидоры. "... от костыля к РСУБД..." - смотря как делать. Можно и расширение костылем назвать, только в печку совать не надо. :) РСУБД - достаточно эффективно решают тот круг задач, в которых они используются, почему надо от этого отказываться? 4. Вот за это - спасибо. Будут вопросы, не решаемые имеющейся поддержкой местных mumps-истов - задам обязательно. Повторюсь: есть большое подозрение, что к обсуждаемой задаче - оно имеет самое прямое отношение. :) Сразу: насколько Вы хорошо разбираетесь в исходном коде этого движка? У меня сложилось впечатление, что вполне допустимо заменить язык М на json формат... или я ещё не всё там нашел? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2012, 12:01 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
АнатоЛойБредятинапропущено... Странное отношение к реляционным БД. Не ожидал, честно говоря) Мой комментарий стоит воспринимать так: Интересное предисловие:) То есть, сам комментарий настолько непонятен?:) АнатоЛой1. mumps - лучший выбор для такой задачи. Без аргументов это "высокомерная бредятина". Разумеется, технических аргументов у Вас никогда не было ни по одному вопросу:) АнатоЛой2. Как, впрочем, и для любой другой:) Без аргументов это "бредятина, поскольку полностью потеряна связь с реальностью". Разумеется, технических аргументов у Вас нет, в то время, как я четко показал бесполезность SQL, и даже нашел и обосновал одну сферу применения алгебры, когда она не противоречит семантике и, безусловно, полезна:) Это к задаче обсуждаемой не относится, но раз у Вас по обсуждаемой задаче аргументов нет, то полезно напомнить Вам некоторые факты, для общего развития:) АнатоЛой3. "Но здесь преимущества ее свойств, вероятно, очевидны даже для поклонников реляционной технологии." Это бредятина, вытекающая из уверенности, что все "поклонники реляционной технологии" точно знают о mumps и её реинкарнациях реализациях, а также разделяют точку зрения Бредятины о её свойствах для данной задачи. То, что люди, считающие себя специалистами в области БД, не знакомы с технологиями БД, я согласен. Но не все, к счастью:) Слово "все" употребили Вы, а не я, так как по-существу Вам сказать нечего. АнатоЛой4 "Бредятина..." = "Бредятина держит стиль" Разумеется. Мой стиль помогает Вам развиваться:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2012, 12:23 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2012, 12:51 |
|
||
|
База с большим количеством мелких записей.
|
|||
|---|---|---|---|
|
#18+
БредятинаАнатоЛойпропущено... Мой комментарий стоит воспринимать так: Интересное предисловие:) То есть, сам комментарий настолько непонятен?:) Нет, просто ваш комментарий на него меня озадачил. Решил уточнить :) Бредятина ...про аргументы с обеих сторон ... Не опускаясь в технические детали: на этом уровне они излишни. Были отличные технические детали от V&N. Я же не агитировал за другие варианты, типа mumps :). Вот и обозначил - агитация, никаких аргументов. АнатоЛой4 "Бредятина..." = "Бредятина держит стиль" Разумеется. Мой стиль помогает Вам развиваться:)[/quot] Это бесспорно. Надеюсь хоть в какой-то мере это взаимно :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2012, 13:00 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37936121&tid=1541562]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 366ms |

| 0 / 0 |
