Сохранение данных в файл

Библиотеку для сериализации/десериализации CVS подскажешь?

Для структуры с двумя полями? Ты издеваешься или не выдохнул до сих пор?

Но просто for something completely different: в чем проблема написать генератор кода? gccxml, python - для POD вообще никаких проблем.

а потом к структурке добавится еще одно поле, или изменится тип данных

А потом случится конец света. Что, не случится? Так и добавление поля может не случится.

дык не читай

What is seen cannot be unseen.

А потом случится конец света. Что, не случится? Так и добавление поля может не случится.

конечно, это совсем невероятно, что я только себе придумал, и надежность при хранении данных тоже не нужна, ведь вероятность порчи CSV файла равна вероятности изменений в данных, изменений в коде программы и собс-но наступления конца света

Для структуры с двумя полями?

Почему же обязательно с двумя? Может, у него там еще десяток структур поразлапистее.

И даже в приведенной структуре есть строчка, в которой теоретически могут быть запятые, кавычки, переносы строки или еще какие-нибудь нуждающиеся в специальной обработке символы. В духе my name is «Robert'); DROP TABLE Students; --». Если уж заговорили про CSV, хочется удобного и проверенного решения, без велосепидорства.

в чем проблема написать генератор кода?

Я хотел узнать, какими генераторами пользуются те, кто на практике хранит данные в CSV.

в чем проблема написать генератор кода? gccxml

а ведь и правда, генератор кода на gccxml + csv = лучший способ сохранить «структурку с двумя полями» (с)

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

Смотрим в ТЗ: «Изучаю CPP и пишу не большую программку, необходимо реализовать сохранение данных в файл. Я сперва взялся за sqlite но мне стало интересно как можно самому организовать подобие бд». Где ты тут видишь ACID? На кой ляд нужен готовый sqlite человеку, который хочет понять, как работает БД внутри? Ему нужна книга по структурам данных и простейший формат хранения.

На кой ляд нужен готовый sqlite человеку, который хочет понять, как работает БД внутри?

sqlite как раз нужен - там есть доки, как и сравнение с bdb и пр., а вот на кой ляд ему нужен твой CSV?

Почему же обязательно с двумя?

Потому что только одна структура фигурирует в ТЗ.

Может, у него там еще десяток структур поразлапистее.

Десяток? Всё равно CSV. Вот если он захочет написать свой маленький DDL... тогда можно думать. Хотя словарь данных всё равно будет иметь фиксированную структуру.

Если уж заговорили про CSV, хочется удобного и проверенного решения, без велосепидорства.

У тебя ынтерпрайз головного мозга. Почитай уже ТЗ.

Я хотел узнать, какими генераторами пользуются те, кто на практике хранит данные в CSV.

Я последние 10 лет вообще не храню данных. Хотя генераторы кода с gccxml (с привязкам к python) и python иногда пишу.

научись уже отвечать тому, кто написал сообщение

На кой ляд нужен готовый sqlite человеку, который хочет понять, как работает БД внутри?

sqlite как раз нужен

sqlite - возможно, libsqlite.so - для чего?

а вот на кой ляд ему нужен твой CSV?

Сохранить структуру с двумя полями.

Я последние 10 лет вообще не храню данных.

А, так у нас в треде появился авторитетный теоретик. С этого и надо было начинать.

Shit happens, bro. Но тебе я тоже ответил.

libsqlite.so - для чего?

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

Сохранить структуру с двумя полями.

крайне неудачный пример «организовать подобие бд»

А, так у нас в треде появился авторитетный теоретик.

Ну он появился гораздо позже авторитетных практиков с дислексией.

Ну он появился гораздо позже авторитетных практиков с дислексией.

но он тоже не может похвастаться ее отсутствием ;)

libsqlite.so - для чего?

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

Смотреть на предмет реализации нужно в исходники (а лучше - в учебники и исходники), а вот зачем libsqlite.so - непонятно.

крайне неудачный пример

Из хедпоста я больше не вытащил, фантазировать не хочу.

но он тоже не может похвастаться ее отсутствием ;)

Я хотя бы стараюсь понять %)

а вот зачем libsqlite.so - непонятно

«в конечном итоге - использовать вместо своего велосипеда»

Из хедпоста я больше не вытащил,

ТС как минимум хотел иметь прямой доступ к записи по известному смещению, что CSV не умеет

а вот зачем libsqlite.so - непонятно

«в конечном итоге - использовать вместо своего велосипеда»

Когда велосипед будет написан, его ограничения осознаны, и сам он выброшен - может быть.

ТС как минимум хотел иметь прямой доступ к записи по известному смещению

Я это пропустил. Процитируешь?

Когда велосипед будет написан, его ограничения осознаны, и сам он выброшен - может быть.

согласен

Я это пропустил. Процитируешь?

«Пока два варианта. Сделать name массивом или два файла, один смещения хранит другой данные. »

«Пока два варианта. Сделать name массивом или два файла, один смещения хранит другой данные. »

Кхм. Насколько я понял, это относилось к тому, как записать в файл строки переменной длины. Прямой доступ к записи не обязателен. И кстати, судя по предложению XML, ты тоже не считаешь прямой доступ необходимым ;)

Кхм. Насколько я понял, это относилось к тому, как записать в файл строки переменной длины. Прямой доступ к записи не обязателен.

для записи строк переменной длины не нужны ни массивы, ни хранения смещений, собс-но CSV так и хранит, а то что написал ТС нужно для одной цели - найти запись в файле и ее размер без предварительного чтения всех предыдущих записей

И кстати, судя по предложению XML, ты тоже не считаешь прямой доступ необходимым ;)

то я просто не читал пост ТС :)

для записи строк переменной длины не нужны ни массивы, ни хранения смещений, собс-но CSV так и хранит

Ну мне-то можешь не объяснять %)

то что написал ТС нужно для одной цели - найти запись в файле и ее размер без предварительного чтения всех предыдущих записей

Если ТС появится, он скажет, что имел в виду.

45сек, т.е. на 10млн записей обвала нет

Индексы зачем убрал? И почему ты это делаешь в одной транзакции?

не только можно, но sqlite еще и

и писать можно? а как оно работает с блокировками?

кэш расшарит

bdb это умеет испокон веков

При разрастании базы до десятков гигабайт, sqlite и правда встаёт на колени.

Ты на порядок ошибся, а то и на два. Гораздо раньше оно встанет.

для чего-то большего логично брать тот же postgre, чтоб раскидывать нагрузку и трафик по серверам

Кстати, та задача что у нас сейчас в bdb живет раньше жила в оракле, а вынесли задачу из оракла из-за недостаточной производительности. Если уж оракл не справился, то куда там какому-то postgresql :)

Так и есть, например захочу я считать 10 структуру в файле то мне нужно пройтись с 1 по 10 структуру, а потом захочу 5 структуру и снова нужно вычислять с 1 по 5, то есть за две операции с 1 по 5 посчитаны дважды.

Пока остановился на том, что ставить в файл маркер начала/конца структуры и размер структуры и при начале работы считывать одно поле name у каждой записи и запоминать смещение. Потом как мне видится чтобы узнать у произвольной структуры age не надо перечитывать весь файл.

Если ты не велосипедишь СУБД общего назначения, сделай размер записи фиксированным.

Индексы зачем убрал?

sqlite и так ведет «индекс» по recid, остальные индексы нужны только для поиска по значению, т.е. опциональны

И почему ты это делаешь в одной транзакции?

так быстрее

и писать можно?

конечно можно

а как оно работает с блокировками?

«readers do not block writers and a writer does not block readers»

Кстати, та задача что у нас сейчас в bdb живет раньше жила в оракле, а вынесли задачу из оракла из-за недостаточной производительности. Если уж оракл не справился, то куда там какому-то postgresql :)

какой-то postgre умеет шардинг и балансирование нагрузки, bdb может этим похвастаться? про общий набор возможностей и говорить не стоит

sqlite и так ведет «индекс» по recid, остальные индексы нужны только для поиска по значению, т.е. опциональны

так это не интересно, в реальном мире по записи надо сделать десяток индексов

так быстрее

да, но далеко от реальности

Вот пример, как я сохраняю структуру в бинарный формат

Херово сохраняешь. Из основных недочетов — посчитай количество сисколлов на одну запись. man fwrite, если сам не можешь буферизацию записи в userspace обеспечить.

Затем, если у тебя что-то не записалось, то в файле останется фарш. Например, в определенных условиях (не по дефолту), read и write могут сразу же возвращаться с EINTR от поступления сигнала. Эта абсолютно нормальная ситуация вызовет отказ твоей «сериализации».

Ну и совсем по мелочи: зачем 4 (ЧЕТЫРЕ!) байта на длину строки?

В общем, открой для себя google protocol buffers.

какой-то postgre умеет шардинг

ручной шардинг можно сделать где угодно

балансирование нагрузки

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

про общий набор возможностей и говорить не стоит

в bdb ты можешь на самом низком уровне реализовать оптимальную схему хранения исключительно под свои данные и за счет этого ты будешь рвать всякие ораклы даже на одной машине

в реальном мире по записи надо сделать десяток индексов

далеко не всегда

да, но далеко от реальности

совсем нет, данные вполне могут приходить порциями, но таки да - это далеко не всегда так, если убрать транзакцию, то будет раз в 7-8 медленнее

ручной шардинг можно сделать где угодно
париться с распределенными транзакциями
ты можешь на самом низком уровне реализовать

здорово

Ага, bdb это такой конструктор в котором есть все детали для реализации системы какой угодно сложности.

Использовал скулайт при парсинге вконтактика, база в 7 гигов вполне читалась и писалась.

Ага, bdb это такой конструктор

в sqlite еще больше возможностей - можно сделать свою реализацию хранилища, менеджера памяти, кэша, выносить реализацию отдельных таблиц и индексов во что угодно, создавать свои функции и пр. и пр., причем это «официальные» возможности, только пусть это делает кто-то другой, а я возьму готовое, за 5 мин настрою и при росте нагрузки просто скажу, что надо купить еще пару серверов

в sqlite еще больше возможносте

«возможности» реализуются путем переписывания sqlite? нафиг нафиг! в bdb есть уже всё готовое, надо просто взять и правильным образом соединить

а я возьму готовое, за 5 мин настрою

такое бывает только в сказке

«возможности» реализуются путем переписывания sqlite?

нет конечно, у sqlite есть система расширений

в bdb есть уже всё готовое

да, ну расскажи как к bdb приаттачить csv файл, например

такое бывает только в сказке

такое бывает при прямых руках и должном опыте

нет конечно, у sqlite есть система расширений

это не то, это считай, что самому надо реализовывать, а в bdb уже есть всё реализованное, надо остается только API дергать

да, ну расскажи как к bdb приаттачить csv файл, например

как-то так

while (<>) {
   my ($k, $v) = split(/,/, $_, 2);
   $db->put($k, $v);
}

такое бывает при прямых руках и должном опыте

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

приаттачить csv файл

уточню задачу, чтоб потом не было претензий, на диске есть csv файл, который содержит «таблицу» на два столбика key=value, которая:

а) может читаться и писаться средствами СУБД без промежуточного хранения где-либо еще б) автоматически обновляется, например, при использовании триггеров в) на ней можно строить сложные запросы с участием других данных из нескольких БД г) любая сторонняя программа тоже может напрямую менять/читать этот csv

как-то так

читай выше, я так и знал, что схалтуришь

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

конечно - ведь выбор так велик, наверняка в этом списке целых две СУБД от Oracle?

да и то потом под нагрузками вылезут проблемы

«шардинг» (с), все уже готово, нет смысла нагружать сервера на 100%

Еще один любитель универсальных решений.

посчитай количество сисколлов на одну запись

Я знаю про эту проблему. Да, оно сохраняет относительно медленно. Но *относительно* другого парсера - быстро, и меня производительность устраивает.

Затем, если у тебя что-то не записалось, то в файле останется фарш.

Если ошибка вернулась, то то, что в есть файле - мне уже все равно.

Например, в определенных условиях (не по дефолту), read и write могут сразу же возвращаться с EINTR от поступления сигнала.

Здравая мысль, но эта твоя «нормальная ситуация» у меня нормальной не является (такова специфика проекта). Посылка приложению сигналов не нужна, я использую другие IPC.

зачем 4 (ЧЕТЫРЕ!) байта на длину строки?

А меня жаба не давит.

В общем, открой для себя google protocol buffers.

А вот за это - спасибо, почитаю.

Да, и откуда ты знаешь, что fwrite не дергает write по каждому поводу, а буферизует во внутренний буфер?

конечно - ведь выбор так велик, наверняка в этом списке целых две СУБД от Oracle?

Да куча их. Если нужна горизонтальная масштабируемость, то на sql я вообще смотреть не буду.

«шардинг» (с), все уже готово, нет смысла нагружать сервера на 100%

Как делать шардинг? По какому ключу? Что происходит с ключами про добавлении машин? Что ты будешь делать если надо реплицироваться в другой ДЦ? ... да over 9000 проблем. За 5 минут такие вопросы не решаются.

Да куча их.

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

Как делать шардинг? ...

для каждой СУБД и задачи по своему, для postgre, например, хороший вариант - pl/proxy

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

Если нужно глобально, надежно, масштабируемо, то я буду смотреть hbase, cassandra, elliptics, ...