Чи неефективно зберігати дані як json у простому тексті?

Ми потребували постійного зберігання ключів API, і я придумав читання і написання json у простому тексті, і користувач думає, що він працює, але чи він дуже неефективний в порівнянні з реляційними dbms?

Я просто зберігаю дані як json, а потім редагую вручну для цього випадку використання.

[
    {
        "241103000000056": {
            "Value": "xxx-4c85-xxx-8420-xxx",
        "account1": "3000",
        "account2": "1910",
   "series": "A"
        },
        "2411030000000516": {
            "Value": "String",
        "account1": "3000",
        "account2": "1910",
   "series": "A"
        },
        "2411030000000562": {
            "Value": "Text",
        "account1": "3000",
        "account2": "1910",
   "series": "A"
        },
        "2411030000000564": {
            "Value": "100",
        "account1": "3000",
        "account2": "1910",
   "series": "A"
        },
        "2411030000000566": {
            "Value": "ZZZ",
        "account1": "3000",
        "account2": "1910",
   "series": "A"
        }
    }
]

Це дає змогу швидко отримати робочий випадок використання, коли мій користувач може вручну додавати ключі API замість того, щоб чекати адміністративного інтерфейсу для бази даних або сховища NoSQL. Змінні є

Value - an API key that the program uses per user account1 - the debit account of the payment account2 - the credit account of the payment

Дані читаються і записуються тільки один раз на день в пакетному процесі для платежів, а набір даних не дуже великий (менше 100 і, ймовірно, завжди буде менше 1000, оскільки ключі API - це торговці та підприємства, а не споживачі).

4
@Bwmat Я оновив питання з інформацією.
додано Автор eli, джерело
@mouviciel Ми отримали його! Хто любить SQL?
додано Автор eli, джерело
Текстові формати, такі як json або xml, мають перевагу в тому, що їх можна читати чи змінювати.
додано Автор gerrit, джерело
Зазначене "дубльоване" запитання виглядає надзвичайно іншим , ніж це.
додано Автор MrG, джерело
Скільки даних зберігається таким чином? Як часто вона читається/змінюється?
додано Автор ell, джерело
@ user949300 я знаю, що я збирався голосувати, щоб відновити, але тоді я помітив, як питання було відредаговано: "ймовірно, завжди менше 1000". При цьому це просто обдурення.
додано Автор candied_orange, джерело
@DjDac Тоді проблеми з продуктивністю незначні, якщо немає величезної кількості рахунків (або інших підполів). Якщо весь файл має порядку десятків мегабайт (або менше), то для завантаження його в пам'ять практично немає часу.
додано Автор ohias, джерело

5 Відповіді

Чи менш ефективним є збереження невеликого біта даних, наприклад, вашого прикладу, закодованого в рядку, а не як двійкового? Так. Наскільки менше? Недостатньо для догляду.

Чи є менш ефективним зберігати тисячі таких записів у рядку, ніж у двійковій? О боже так.

Ось чому: я не можу передбачити індекс "account1" у 42-му записі, оскільки поля попередніх записів не мали фіксованої довжини. Це означає, що я не можу знайти його, не розбираючи все перед ним.

Тепер, звичайно, ви можете зробити текст з фіксованою довжиною також, але ніхто ніколи не поважає, що так ніхто не робить це. З якоїсь дивної причини вони поважають його, коли це робиться у двійковому режимі. Чому? Я не знаю, може бути, ви отримаєте кращий клас кодерів, коли ви змушуєте їх віддалятися в шестнадцятковому редакторі замість блокнота.

Це право є велика база даних дійсно дають вам, що будь-якого значення над вашою файловою системою. Ну, крім угод.

Що стосується 80 байт проти 150 байт? Feh! Якщо б я піклувався про фактор O (n), подібний до цього (я цього не роблю), я б просто застібав цю річ.

Про що я дбаю, виникає проблема schlemiel художника , де я не можу дрібні речі, які перш ніж я міг би зробити добре, тому що кількість даних стала великою. Це не те, що ви можете виправити, просто кинувши більший жорсткий диск на проблему. Подумайте, як ці записи використовуються.

Ось чому люди, які запитують про максимальний розмір файлу системи, перш ніж створювати файли json, дійсно повинні сісти і поговорити.

13
додано
Gzipping прагне добре працювати для текстових форматів, і оскільки він так добре підтримується клієнтами HTTP, ви можете навіть обслуговувати стислі файли безпосередньо, якщо ви хочете отримати фантазії.
додано Автор JimmyJames, джерело

Питання, яке потрібно задати, є ефективним? Схоже, що ваші записи можуть бути збережені більш просторовим способом, передбачаючи фіксовану структуру запису (подібно до бази даних) і зберігаючи значення у двійковій формі.

Номери записів виглядають так, як вони вміщаються в 64-бітну int, тоді як в даний час вони зберігаються в 16 символьних рядках плюс 2 подвійних лапки, плюс форматування. Якщо текстові поля можуть мати обмеження довжини, це також допоможе. Значення облікового запису виглядають так, як вони підходять до 16-бітових ints, хоча ви, ймовірно, хочете 32-бітні ints для масштабування. Отже, скажемо, що рядки "Значення" та "серії" можуть бути обмежені 31 символом плюс байт довжини. Ви дивитеся на всі записи:

  • 8 байтів для номера запису
  • 32 байти для значення
  • 4 байти для облікового запису 1
  • 4 байти для облікового запису 2
  • 32 байти для серії

Це 80 байт на запис. Перший запис у вашому списку - 150 байт. Звичайно, якщо рядки повинні бути не менше 1k, але вони становлять у середньому 150 байт, то це змінює рівняння. Звичайно ж, вам не треба дозволяти, щоб рядки мали фіксовану довжину. Ви можете зберігати байт довжини і мати змінний розмір запису. Тепер дуже ефективно зберігати на диску, але для читання та запису може знадобитися більше часу. Особливо, якщо вам потрібно зробити багато випадкового доступу.

Чи відповідає весь набір записів пам'яті? Тоді, можливо, час повільного читання/запису не має значення, тому що ви тільки читаєте один раз при запуску програми і записуєте один раз при завершенні роботи програми. (Напевно, ні, але я просто даю екстремальний приклад.)

Є способи оптимізувати кожне з цих речей або знайти розумні компроміси для ситуацій, коли оптимізація будь-якої однієї речі призведе до зниження ефективності. Але все залежить від того, що ви збираєтеся робити з цими даними.

5
додано
Так, 100 000 записів має бути можливим. Я просто радий, що ти не назвав мене божевільним.
додано Автор eli, джерело
Хороший аналіз, але в цифрах OP говорять про (100), вони можуть зберігати значення на санскриті і все ще бути достатньо швидко. :-)
додано Автор MrG, джерело
Ха! Надто вірно. Ця інформація була додана під час написання моєї відповіді. Але я думаю, що відповідь залишається актуальною, якщо вони хочуть збільшити її в майбутньому.
додано Автор user1118321, джерело

Для пакетної обробки ефективність не є головним завданням. Зберігайте дані в базі даних. Набагато простіше записувати правильні дані за допомогою sql, ніж редагувати текстовий файл, а також більше перевірок узгодженості з базою даних (якщо ви використовуєте зовнішні ключі і правильні типи даних). Реляційна база даних також відбувається швидше, але ви виконуєте пакетну обробку, тому обробка текстового файлу, ймовірно, буде досить швидкою.

Я розумію, що це протилежне коментарям нижче (JSON так легко з будь-якою мовою, це легко читається людиною, ...). Багато проблем, з якими я стикався, зводилися до того, що хтось не правильно редагував текстовий файл. І так, незважаючи на мій вік, я використовував JSON. Я просто відчуваю, що JSON є оманливо легко робити помилки, які можна перевірити за допомогою загальних обмежень бази даних.

3
додано
@JimmyJames Добре, я його редагував. Я теж працював над проектом, який компанія тільки що купила більше заліза (без знання для мене), і я завів оптимізацію щоденних процесів, які зайняли 27 + годин, щоб запустити їх і запустили їх за 1 хвилину. Це було зроблено в першу чергу шляхом кешування, щоб уникнути іо - те, що безліч людей з магістерськими ступенями, які працювали там, могли/повинні були, але не зробили. Що сказав, я думаю вони би були більш щасливі якщо взяли більше як 1/2 години.
додано Автор Greenhorn, джерело
@Jules, Чому реалізувати перевірку на розумність JSON-файлу, який можна зробити за допомогою обмежень на реляційну базу даних? Це, здається, більше роботи, ніж потрібно. Крім того, я відчуваю, що важче написати неправильний SQL, який містить лише вставки та оновлення, ніж писати неправильний файл JSON. І не всі текстові файли/файли JSON є конфігурацією, деякі містять дані, надані користувачем - наприклад, інформацію про кредит торговельного підприємства.
додано Автор Greenhorn, джерело
@JimmyJames - так, загальна ефективність системи обробки повинна бути достатньо швидкою для роботи (щоденне завдання не може зайняти 27 годин для запуску), але не потрібно використовувати найбільш ефективний код. Онлайнова обробка має дуже суворі часові обмеження, де, як пакетна обробка, як правило, має значно більш вільні часові обмеження.
додано Автор Greenhorn, джерело
Кілька невдалих проектів через використання текстового файлу? Як щодо невдалого проекту, оскільки він не був створений, щоб легко змінити джерело даних?
додано Автор bstpierre, джерело
Я не погоджуюсь. Принаймні для більшості мов взаємодія з аналізатором JSON набагато простіше, ніж використання бази даних.
додано Автор Jules, джерело
"Багато проблем, з якими я стикався, зводилися до того, що хтось не правильно редагував текстовий файл". - Ваші інтеграційні тести повинні включати перевірку правдивості файлів конфігурації, щоб ця ситуація не могла відбутися. Також відзначу, що розгортати неправильний файл SQL так само легко, що робить вашу базу даних непридатною, якщо у вас немає жодного способу тестування таких речей.
додано Автор Jules, джерело
На моєму досвіді, обмеження SQL не є достатніми для запобігання всіх можливих помилок. Тільки тестування запущеної системи і забезпечення її здатності успішно спілкуватися з третіми сторонами і т.д., достатньо для того, щоб безпечно змінити конфігурацію.
додано Автор Jules, джерело
Хоча в даному випадку ефективність, здається, не має великого значення, я повинен поставити під сумнів твердження, що ефективність в дозуванні не має значення. Пакетування має тенденцію відбуватися в певному вікні часу і тому звужує кількість часу, доступного для обробки записів. Це не те, що ефективність не є важливою, це те, що вам потрібно більше турбуватися про пропускну здатність, ніж затримку.
додано Автор JimmyJames, джерело
@RobertBaron На моєму досвіді є загальні проблеми з отриманням пакетів, щоб поміститися всередині вікна обробки. Я бачив, як проблема призвела до того, що мільйони доларів будуть підірвані на великому залізі, тоді як ці партії використовували сортування міхурів для даних про порядок мільйонів елементів, оскільки "ефективність не мала значення". Це різновид загнав мені горіхи.
додано Автор JimmyJames, джерело

З іншої точки зору, ніж інші відповіді:

Я згоден з тим, що СУБД, швидше за все, перебільшує складність простору, але СУБД може також надавати гарантії цілісності даних, а також безпеку. Вони часто мають вбудовані функції резервного копіювання і дозволяють зашифрувати дані на диску (поверх будь-якого шифрування на рівні ОС, який може бути або не бути на місці).

Можливо, це не є прямою відповіддю на ваше запитання, але коли я бачу, що XML, JSON, INI або інші текстові формати, що читаються людиною, зберігають потенційно конфіденційні дані (наприклад, відповідні номери облікових записів з ключами API), я завжди думаю про те, як легко було б для зловмисника, щоб отримати цей файл і використовувати його вміст. Файл навіть визначає, що кожен фрагмент даних означає, що він знаходиться у форматі OP.

Якщо зловмисник отримує цей файл JSON, у нього є все. Вони знають усіх ваших клієнтів і мають доступ до ключів API, що означає, що вони можуть легко отримати доступ до всіх даних, наданих через цей API. СУБД може бути налаштована для шифрування записів окремо. Отже, якщо зловмисник отримає базу даних: Ну, це зашифровано. Якщо зловмисник отримує запис клієнта: Добре, це трохи погано, але вони не мають доступу до всіх записів клієнтів.

Якщо ви намагаєтеся повернути власну цілісність даних, резервні копії, шифрування тощо, я майже гарантую, що ви отримаєте щось не так. СУБД вже багато разів "зробила це неправильно", і всі вони повинні були виправити ці проблеми. Будь-яка сприйнята труднощі при взаємодії з СУБД програмно не є нічим у порівнянні з правильним захистом даних.

Можливо, це не викликає великого занепокоєння - я не знаю, який доступ забезпечують ці ключі API, але згадка про "облікові записи" та "платежі" ставить мене трохи на межі. Це звучить як дані, які необхідно забезпечити належним чином. Космос мудрий кожен абсолютно правий, що збережена сума тривіальна. Але безпечний JSON файл досить страшний.

3
додано
Я думаю, що ми будемо використовувати СУБД і пітон для наступної версії. Ця версія була більше схожа на доказ концепції, що ми можемо зробити це без СУБД.
додано Автор eli, джерело

Для 100-1000 записів, оброблених кілька разів на день, ефективність абсолютно неактуальна . В будь-якому випадку це буде швидше, ніж натискання кнопки.

2
додано
ІТ КПІ - JavaScript
ІТ КПІ - JavaScript
504 учасників

співтовариство javascript розробників в Telegram