Menyimpan Data di MySQL sebagai JSON

Saya pikir ini adalah hal yang harus dilakukan. Dan, jadi, saya tidak pernah melakukannya. Kemudian saya melihat bahwa FriendFeed melakukan ini dan benar-benar membuat skala DB mereka lebih baik dan mengurangi latensi. Saya ingin tahu apakah saya harus melakukan ini. Dan, jika ya, apa cara yang benar untuk melakukannya?

Pada dasarnya, apa tempat yang baik untuk mempelajari cara menyimpan segala sesuatu di MySQL sebagai semacam DB CouchDB? Menyimpan semuanya sebagai JSON sepertinya akan lebih mudah dan lebih cepat (bukan membangun, mengurangi latensi).

Juga, apakah mudah untuk mengedit, menghapus, dll., Hal-hal yang disimpan sebagai JSON di DB?

CouchDB dan MySQL adalah dua binatang yang sangat berbeda. JSON adalah cara asli untuk menyimpan barang di CouchDB. Di MySQL, hal terbaik yang dapat Anda lakukan adalah menyimpan data JSON sebagai teks dalam satu bidang. Ini sepenuhnya akan menggagalkan tujuan menyimpannya dalam RDBMS dan akan sangat mempersulit setiap transaksi database.

Jangan.

Karena itu, FriendFeed tampaknya menggunakan skema yang sangat khusus di atas MySQL. Itu benar-benar tergantung pada apa yang sebenarnya ingin Anda simpan, hampir tidak ada satu jawaban pasti tentang bagaimana menyalahgunakan sistem database sehingga masuk akal bagi Anda. Mengingat bahwa artikel tersebut sangat tua dan alasan utama mereka menentang Mongo dan Couch adalah ketidakdewasaan, saya akan mengevaluasi kembali keduanya jika MySQL tidak memotongnya untuk Anda. Mereka seharusnya sudah tumbuh banyak sekarang.

Semua orang yang berkomentar sepertinya datang dari sudut yang salah, tidak masalah untuk menyimpan kode JSON melalui PHP dalam DB relasional dan sebenarnya akan lebih cepat untuk memuat dan menampilkan data kompleks seperti ini, namun Anda akan memiliki pertimbangan desain seperti mencari, mengindeks, dll.

Cara terbaik untuk melakukan ini adalah dengan menggunakan data hybrid, misalnya jika Anda perlu mencari berdasarkan datetime MySQL (kinerja disetel) akan jauh lebih cepat daripada PHP dan untuk jarak pencarian tempat seperti MySQL juga harus banyak. lebih cepat (perhatikan mencari tidak mengakses). Data yang tidak perlu Anda cari dapat disimpan dalam JSON, BLOB, atau format lain yang Anda anggap perlu.

Data yang perlu Anda akses sangat mudah disimpan sebagai JSON misalnya sistem faktur per kasus dasar. Mereka sama sekali tidak mendapatkan keuntungan dari RDBMS, dan dapat disimpan di JSON hanya dengan json_encoding ($ _ POST ['entires']) jika Anda memiliki struktur form HTML yang benar.

Saya senang Anda senang menggunakan MongoDB dan saya harap ini terus membantu Anda dengan baik, tetapi jangan berpikir bahwa MySQL akan selalu keluar dari radar Anda, karena aplikasi Anda meningkat dalam kompleksitas, Anda mungkin pada akhirnya membutuhkan RDBMS untuk beberapa fungsi dan fitur (meskipun hanya untuk menghentikan data yang diarsipkan atau pelaporan bisnis)

MySQL 5.7 Sekarang mendukung tipe data JSON asli yang mirip dengan MongoDB dan penyimpanan data dokumen tanpa skema lainnya:

Dukungan JSON

Mulai MySQL 5.7.8, MySQL mendukung jenis JSON asli. Nilai JSON tidak disimpan sebagai string, melainkan menggunakan format biner internal yang memungkinkan akses baca cepat ke elemen dokumen. Dokumen JSON yang disimpan di kolom JSON secara otomatis divalidasi setiap kali dimasukkan atau diperbarui, dengan dokumen yang tidak valid menghasilkan kesalahan. Dokumen JSON dinormalisasi saat pembuatan, dan dapat dibandingkan dengan menggunakan sebagian besar operator perbandingan seperti =, <, <=,>,> =, <>,! =, Dan <=>; untuk informasi tentang operator yang didukung serta prioritas dan aturan lain yang diikuti MySQL saat membandingkan nilai JSON, lihat Perbandingan dan Urutan Nilai JSON.

MySQL 5.7.8 juga memperkenalkan sejumlah fungsi untuk bekerja dengan nilai JSON. Fungsi-fungsi ini termasuk yang tercantum di sini:

1. Fungsi yang membuat nilai JSON: JSON_ARRAY (), JSON_MERGE (), dan JSON_OBJECT (). Lihat Bagian 12.16.2, “Fungsi yang Menciptakan Nilai JSON”.
2. Fungsi yang mencari nilai JSON: JSON_CONTAINS (), JSON_CONTAINS_PATH (), JSON_EXTRACT (), JSON_KEYS (), dan JSON_SEARCH (). Lihat Bagian 12.16.3, “Fungsi yang Mencari Nilai JSON”.
3. Fungsi yang mengubah nilai JSON: JSON_APPEND (), JSON_ARRAY_APPEND (), JSON_ARRAY_INSERT (), JSON_INSERT (), JSON_QUOTE (), JSON_REMOVE (), JSON_REPLACE (), JSON_SET (), dan JSON_UNQUOTE (). Lihat Bagian 12.16.4, “Fungsi yang Mengubah Nilai JSON”.
4. Fungsi yang memberikan informasi tentang nilai JSON: JSON_DEPTH (), JSON_LENGTH (), JSON_TYPE (), dan JSON_VALID (). Lihat Bagian 12.16.5, “Fungsi yang Mengembalikan Atribut Nilai JSON”.

Di MySQL 5.7.9 dan yang lebih baru, Anda dapat menggunakan kolom-> jalur sebagai singkatan dari JSON_EXTRACT (kolom, jalur). Ini berfungsi sebagai alias untuk kolom di mana pun pengidentifikasi kolom dapat muncul dalam pernyataan SQL, termasuk klausa WHERE, ORDER BY, dan GROUP BY. Ini termasuk SELECT, UPDATE, DELETE, CREATE TABLE, dan pernyataan SQL lainnya. Sisi kiri harus berupa pengidentifikasi kolom JSON (dan bukan alias). Sisi kanan adalah ekspresi jalur JSON yang dikutip yang dievaluasi terhadap dokumen JSON yang dikembalikan sebagai nilai kolom.

Lihat Bagian 12.16.3, “Fungsi yang Mencari Nilai JSON”, untuk informasi lebih lanjut tentang -> dan JSON_EXTRACT (). Untuk informasi tentang dukungan jalur JSON di MySQL 5.7, lihat Mencari dan Memodifikasi Nilai JSON. Lihat juga Indeks Sekunder dan Kolom yang Dihasilkan Virtual.

Info lebih lanjut:

https://dev.mysql.com/doc/refman/5.7/en/json.html

karakter json tidak ada yang istimewa dalam hal penyimpanan, karakter seperti

{, }, [, ], ', a-z, 0-9.... benar-benar tidak ada yang istimewa dan dapat disimpan sebagai teks.

masalah pertama yang akan Anda hadapi adalah ini

{profile_id: 22, nama pengguna: 'Robert', sandi: 'skhgeeht893htgn34ythg9er'}

yang disimpan dalam database tidak sesederhana itu untuk diperbarui kecuali Anda memiliki proses sendiri dan mengembangkan jsondecode untuk mysql

UPDATE users SET JSON(user_data,'username') = 'New User';

Jadi karena Anda tidak dapat melakukannya, Anda harus terlebih dahulu MEMILIH json, memecahkan kode, mengubahnya, memperbaruinya, jadi secara teori Anda mungkin juga menghabiskan lebih banyak waktu untuk membangun struktur database yang sesuai!

Saya menggunakan json untuk menyimpan data tetapi hanya Meta Data, data yang tidak sering diperbarui, tidak terkait dengan spesifik pengguna .. contoh jika pengguna menambahkan posting, dan dalam posting itu dia menambahkan gambar, parsing gambar dan buat jempol dan lalu gunakan url jempol dalam format json.

Untuk menggambarkan betapa sulitnya mendapatkan data JSON menggunakan kueri, saya akan membagikan kueri yang saya buat untuk menangani ini.

Ini tidak memperhitungkan array atau objek lain, hanya tipe data dasar. Anda harus mengubah 4 kolom menjadi nama kolom yang menyimpan JSON, dan mengubah 4 kolom myfield ke kolom JSON yang ingin Anda akses.

SELECT
    SUBSTRING(
        REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
        LOCATE(
            CONCAT('myfield', ':'),
            REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
        ) + CHAR_LENGTH(CONCAT('myfield', ':')),
        LOCATE(
            ',',
            SUBSTRING(
                REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
                LOCATE(
                    CONCAT('myfield', ':'),
                    REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
                ) + CHAR_LENGTH(CONCAT('myfield', ':'))
            )
        ) - 1
    )
    AS myfield
FROM mytable WHERE id = '3435'

Itu sangat tergantung pada kasus penggunaan Anda. Jika Anda menyimpan informasi yang sama sekali tidak memiliki nilai dalam pelaporan, dan tidak akan dikueri melalui GABUNG dengan tabel lain, mungkin masuk akal bagi Anda untuk menyimpan data Anda dalam satu bidang teks, yang dikodekan sebagai JSON.

Ini bisa sangat menyederhanakan model data Anda. Namun, seperti yang disebutkan RobertPitt, jangan berharap bisa menggabungkan data ini dengan data lain yang sudah dinormalisasi.

Ini adalah pertanyaan lama, tetapi saya masih dapat melihat ini di bagian atas hasil pencarian Google, jadi saya rasa akan sangat berarti jika menambahkan jawaban baru 4 tahun setelah pertanyaan tersebut diajukan.

Pertama-tama, ada dukungan yang lebih baik dalam menyimpan JSON di RDBMS. Anda dapat mempertimbangkan untuk beralih ke PostgreSQL (meskipun MySQL telah mendukung JSON sejak v5.7.7). PostgreSQL menggunakan perintah SQL yang sangat mirip dengan MySQL kecuali mereka mendukung lebih banyak fungsi. Salah satu fungsi yang mereka tambahkan adalah bahwa mereka menyediakan tipe data JSON dan Anda sekarang dapat menanyakan JSON yang disimpan. ( Beberapa referensi tentang ini ) Jika Anda tidak membuat kueri secara langsung di program Anda, misalnya, menggunakan PDO di php atau fasih di Laravel, yang perlu Anda lakukan hanyalah menginstal PostgreSQL di server Anda dan mengubah pengaturan koneksi database. Anda bahkan tidak perlu mengubah kode Anda.

Sering kali, seperti yang disarankan oleh jawaban lain, menyimpan data sebagai JSON secara langsung di RDBMS bukanlah ide yang baik. Ada beberapa pengecualian. Satu situasi yang dapat saya pikirkan adalah bidang dengan jumlah variabel entri tertaut.

Misalnya, untuk menyimpan tag postingan blog, biasanya Anda memerlukan tabel untuk postingan blog, tabel tag, dan tabel yang cocok. Jadi, ketika pengguna ingin mengedit posting dan Anda perlu menampilkan tag mana yang terkait dengan posting itu, Anda perlu menanyakan 3 tabel. Ini akan sangat merusak kinerja jika tabel / tabel tag yang cocok Anda panjang.

Dengan menyimpan tag sebagai JSON di tabel posting blog, tindakan yang sama hanya memerlukan satu pencarian tabel. Pengguna kemudian akan dapat melihat posting blog yang akan diedit lebih cepat, tetapi ini akan merusak kinerja jika Anda ingin membuat laporan tentang posting apa yang ditautkan ke tag, atau mungkin mencari berdasarkan tag.

Anda juga dapat mencoba untuk menormalkan database. Dengan menduplikasi data dan menyimpan data dengan kedua cara, Anda dapat memperoleh manfaat dari kedua metode tersebut. Anda hanya perlu sedikit lebih banyak waktu untuk menyimpan data dan lebih banyak ruang penyimpanan (yang lebih murah dibandingkan dengan biaya lebih banyak daya komputasi)

Saya akan mengatakan dua alasan untuk mempertimbangkan ini adalah:

• kinerja tidak cukup baik dengan pendekatan yang dinormalisasi
• Anda tidak dapat dengan mudah memodelkan data Anda yang sangat fleksibel / fleksibel

Saya menulis sedikit tentang pendekatan saya sendiri di sini:

Masalah skalabilitas apa yang Anda temui saat menggunakan penyimpanan data NoSQL?

(lihat jawaban teratas)

Bahkan JSON tidak cukup cepat sehingga kami menggunakan pendekatan format teks khusus. Bekerja / terus bekerja dengan baik untuk kami.

Apakah ada alasan Anda tidak menggunakan sesuatu seperti MongoDB? (mungkin MySQL "diperlukan"; hanya ingin tahu)

Bagi saya, semua orang yang menjawab pertanyaan ini sepertinya kehilangan satu masalah kritis, kecuali @deceze - gunakan alat yang tepat untuk pekerjaan itu . Anda dapat memaksa database relasional untuk menyimpan hampir semua jenis data dan Anda dapat memaksa Mongo untuk menangani data relasional, tetapi berapa biayanya? Anda akhirnya akan memperkenalkan kompleksitas di semua tingkat pengembangan dan pemeliharaan, dari desain skema hingga kode aplikasi; belum lagi performa hitnya.

Pada tahun 2014 kami memiliki akses ke banyak server database yang menangani jenis data tertentu dengan sangat baik.

• Mongo (penyimpanan dokumen)
• Redis (penyimpanan data nilai kunci)
• MySQL / Maria / PostgreSQL / Oracle / etc (data relasional)
• CouchDB (JSON)

Saya yakin saya merindukan beberapa yang lain, seperti RabbirMQ dan Cassandra. Maksud saya adalah, gunakan alat yang tepat untuk data yang perlu Anda simpan.

Jika aplikasi Anda memerlukan penyimpanan dan pengambilan berbagai data dengan sangat, sangat cepat, (dan siapa yang tidak) jangan malu menggunakan berbagai sumber data untuk suatu aplikasi. Kerangka web paling populer menyediakan dukungan untuk berbagai sumber data (Rails, Django, Grails, Cake, Zend, dll). Strategi ini membatasi kompleksitas pada satu area spesifik aplikasi, ORM, atau antarmuka sumber data aplikasi.

Berikut adalah fungsi yang akan menyimpan / memperbarui kunci dari larik JSON dalam kolom dan fungsi lain yang mengambil nilai JSON. Fungsi ini dibuat dengan asumsi bahwa nama kolom untuk menyimpan array JSON adalah json . Ini menggunakan PDO .

Simpan / Perbarui Fungsi

function save($uid, $key, $val){
 global $dbh; // The PDO object
 $sql = $dbh->prepare("SELECT `json` FROM users WHERE `id`=?");
 $sql->execute(array($uid));
 $data      = $sql->fetch();
 $arr       = json_decode($data['json'],true);
 $arr[$key] = $val; // Update the value
 $sql=$dbh->prepare("UPDATE `users` SET `json`=? WHERE `id`=?");
 $sql->execute(array(
   json_encode($arr), 
   $uid
 ));
}

di mana $ uid adalah id pengguna, $ key - kunci JSON untuk diperbarui dan nilainya disebutkan sebagai $ val .

Dapatkan Fungsi Nilai

function get($uid, $key){
 global $dbh;
 $sql = $dbh->prepare("SELECT `json` FROM `users` WHERE `id`=?");
 $sql->execute(array($uid));
 $data = $sql->fetch();
 $arr  = json_decode($data['json'], true);
 return $arr[$key];
}

di mana $ key adalah kunci dari array JSON dari mana kita membutuhkan nilainya.

Dukungan awal untuk menyimpan JSON di MySQL telah ditambahkan ke rilis JSON labs MySQL 5.7.7 ( binari linux , sumber )! Rilis ini tampaknya telah berkembang dari serangkaian fungsi yang ditentukan pengguna terkait JSON yang dipublikasikan pada tahun 2013 .

Dukungan JSON asli yang baru lahir ini tampaknya menuju ke arah yang sangat positif, termasuk validasi JSON pada INSERT, format penyimpanan biner yang dioptimalkan termasuk tabel pencarian di pembukaan yang memungkinkan fungsi JSN_EXTRACT untuk melakukan pencarian biner daripada mengurai pada setiap akses. Ada juga serangkaian fungsi baru untuk menangani dan menanyakan tipe data JSON tertentu:

CREATE TABLE users (id INT, preferences JSON);

INSERT INTO users VALUES (1, JSN_OBJECT('showSideBar', true, 'fontSize', 12));

SELECT JSN_EXTRACT(preferences, '$.showSideBar') from users;

+--------------------------------------------------+
| id   | JSN_EXTRACT(preferences, '$.showSideBar') |
+--------------------------------------------------+
| 1    | true                                      |
+--------------------------------------------------+

IMHO, di atas adalah kasus penggunaan yang bagus untuk fungsi baru ini; banyak database SQL sudah memiliki tabel pengguna dan, daripada membuat perubahan skema tanpa akhir untuk mengakomodasi serangkaian preferensi pengguna yang berkembang, memiliki satu kolom JSON satu JOINsaja sudah sempurna. Terutama karena tidak mungkin perlu ditanyai untuk masing-masing item.

Sementara itu masih dini hari, tim server MySQL melakukan pekerjaan yang besar mengkomunikasikan perubahan pada para blog .

Saya percaya bahwa menyimpan JSON dalam database mysql sebenarnya mengalahkan tujuan penggunaan RDBMS seperti yang dimaksudkan untuk digunakan. Saya tidak akan menggunakannya dalam data apa pun yang akan dimanipulasi di beberapa titik atau dilaporkan, karena tidak hanya menambah kompleksitas tetapi juga dapat dengan mudah memengaruhi kinerja tergantung pada bagaimana penggunaannya.

Namun, saya penasaran jika ada orang lain yang memikirkan kemungkinan alasan untuk benar-benar melakukan ini. Saya berpikir untuk membuat pengecualian untuk tujuan penebangan. Dalam kasus saya, saya ingin mencatat permintaan yang memiliki jumlah variabel parameter dan kesalahan. Dalam situasi ini, saya ingin menggunakan tabel untuk jenis permintaan, dan permintaan itu sendiri dengan string JSON dengan nilai berbeda yang diperoleh.

Dalam situasi di atas, permintaan dicatat dan tidak pernah dimanipulasi atau diindeks dalam bidang string JSON. NAMUN, dalam lingkungan yang lebih kompleks, saya mungkin akan mencoba menggunakan sesuatu yang lebih bertujuan untuk jenis data ini dan menyimpannya dengan sistem itu. Seperti yang dikatakan orang lain, itu benar-benar tergantung pada apa yang Anda coba capai, tetapi mengikuti standar selalu membantu umur panjang dan keandalan!

JSON juga merupakan tipe data yang valid dalam database PostgreSQL. Namun, database MySQL belum mendukung JSON secara resmi. Tapi itu memanggang: http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

Saya juga setuju bahwa ada banyak kasus yang valid bahwa beberapa data sebaiknya diserialkan ke string dalam database. Alasan utamanya mungkin ketika tidak dikueri secara teratur, dan ketika skemanya sendiri mungkin berubah - Anda tidak ingin mengubah skema database yang sesuai dengan itu. Alasan kedua adalah ketika string berseri langsung dari sumber eksternal, Anda mungkin tidak ingin mengurai semuanya dan memasukkannya ke dalam database dengan biaya berapa pun hingga Anda menggunakannya. Jadi saya akan menunggu rilis MySQL baru untuk mendukung JSON karena akan lebih mudah untuk beralih di antara database yang berbeda.

Saya menggunakan json untuk merekam apa pun untuk sebuah proyek, sebenarnya saya menggunakan tiga tabel! satu untuk data di json, satu untuk indeks setiap metadata dari struktur json (setiap meta dikodekan oleh id unik), dan satu untuk pengguna sesi, itu saja. Tolok ukur tidak dapat dihitung pada status awal kode ini, tetapi sebagai contoh saya adalah pandangan pengguna (gabungan dalam dengan indeks) untuk mendapatkan kategori (atau apa pun, sebagai pengguna, ...), dan itu sangat lambat (sangat sangat lambat , tampilan yang digunakan di mysql bukan cara yang baik). Modul pencarian, dalam struktur ini, dapat melakukan apapun yang saya inginkan, tetapi menurut saya mongodb akan lebih efisien dalam konsep pencatatan data json penuh ini. Sebagai contoh saya, saya menggunakan pandangan pengguna untuk membuat pohon kategori, dan remah roti, my god! begitu banyak pertanyaan yang harus dilakukan! Apache sendiri hilang! dan, sebenarnya, untuk situs web kecil ini, saya menggunakan tahu php yang menghasilkan pohon dan remah roti, ekstraksi data dilakukan oleh modul pencarian (yang hanya menggunakan indeks), tabel data digunakan hanya untuk pembaruan. Jika saya mau, saya dapat menghancurkan semua indeks, dan memperbaruinya dengan setiap data, dan melakukan pekerjaan sebaliknya untuk, seperti, menghancurkan semua data (json) dan membuatnya kembali hanya dengan tabel indeks. Proyek saya masih muda, berjalan di bawah php dan mysql, tetapi, kadang-kadang saya menggunakan node js dan mongodb akan lebih efisien untuk proyek ini.

Gunakan json jika Anda pikir Anda bisa melakukannya, lakukan saja, karena Anda bisa! dan, lupakan jika itu adalah kesalahan; mencoba dengan membuat pilihan yang baik atau buruk, tapi cobalah!

Rendah

pengguna prancis

Saya tahu ini benar-benar terlambat tetapi saya memiliki situasi serupa di mana saya menggunakan pendekatan hybrid untuk mempertahankan standar RDBMS dari tabel normalisasi hingga titik dan kemudian menyimpan data dalam JSON sebagai nilai teks di luar titik itu. Jadi misalnya saya menyimpan data dalam 4 tabel mengikuti aturan normalisasi RDBMS. Namun pada tabel ke-4 untuk mengakomodasi skema dinamis saya menyimpan data dalam format JSON. Setiap kali saya ingin mengambil data, saya mengambil data JSON, mengurai dan menampilkannya di Java. Ini telah berhasil untuk saya sejauh ini dan untuk memastikan bahwa saya masih dapat mengindeks bidang yang saya ubah menjadi data json dalam tabel ke cara yang dinormalisasi menggunakan ETL. Ini memastikan bahwa saat pengguna mengerjakan aplikasi, ia menghadapi kelambatan minimal dan bidang diubah ke format yang ramah RDBMS untuk analisis data, dll.

Anda dapat menggunakan inti ini: https://gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

Setelah menginstalnya ke server (hanya perlu hak akses root bukan super), Anda dapat melakukan sesuatu seperti ini:

select extract_json_value('{"a":["a","2"]}','(/a)')

Ini akan kembali a 2 . Anda dapat mengembalikan apa pun di dalam JSON dengan menggunakan ini Bagian yang baik adalah ia mendukung MySQL 5.1,5.2,5.6. Dan Anda tidak perlu menginstal biner apa pun di server.

Berdasarkan proyek lama common-schema, tetapi masih berfungsi hingga hari ini https://code.google.com/archive/p/common-schema/