TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

JSONB has landed

669 点作者 nalgeon超过 1 年前

30 条评论

luhn超过 1 年前
Lots of confusion on what JSONB is.<p>To your application, using JSONB looks very similar to the JSON datatype. You still read and write JSON strings—Your application will never see the raw JSONB content. The same SQL functions are available, with a different prefix (jsonb_). Very little changes from the application&#x27;s view.<p>The difference is that the JSON datatype is stored to disk as JSON, whereas the JSONB is stored in a special binary format. With the JSON datatype, the JSON must be parsed in full to perform any operation against the column. With the JSONB datatype, operations can be performed directly against the on-disk format, skipping the parsing step entirely.<p>If you&#x27;re just using SQLite to write and read full JSON blobs, the JSON datatype will be the best pick. If you&#x27;re querying or manipulating the data using SQL, JSONB will be the best pick.
评论 #38546020 未加载
评论 #38542002 未加载
评论 #38543697 未加载
评论 #38540861 未加载
评论 #38541940 未加载
评论 #38541930 未加载
评论 #38541783 未加载
评论 #38542271 未加载
lake-view超过 1 年前
Because it seems to not be common knowledge on this thread: JSONB is a format offered by Postgres for a while now, and is recommended over plain JSON primarily for improved read performance.<p><a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;datatype-json.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;datatype-json.html</a>
评论 #38540789 未加载
评论 #38540812 未加载
评论 #38543241 未加载
评论 #38540710 未加载
breadchris超过 1 年前
I didnt understand the purposes of document stores until the past couple of years and they are fabulous for building POCs. Enhanced JSON support will help a lot for making sqlite a suitable document store.<p>I get full type support by serializing and deserializing protobuf messages from a db column and not making this column JSONB means i can filter this column too, instead of having to flatten the searchable data to other columns.
评论 #38540914 未加载
nalgeon超过 1 年前
You can try JSONB in the pre-release snapshot [1] or live in the playground [2].<p>[1]: <a href="https:&#x2F;&#x2F;sqlite.org&#x2F;download.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;sqlite.org&#x2F;download.html</a><p>[2]: <a href="https:&#x2F;&#x2F;codapi.org&#x2F;sqlite" rel="nofollow noreferrer">https:&#x2F;&#x2F;codapi.org&#x2F;sqlite</a>
OJFord超过 1 年前
Anyone know what their release process is like, will this be in v3.45? (Downloads page has latest release as 3.44, and TFA says this is in pre-release snapshot.)<p>I don&#x27;t use SQLite directly much, but I&#x27;d be keen to use this in Cloudflare&#x27;s D1 &amp; Fly.io. Having said that though, I&#x27;m not sure they publicise sqlite version (or even that it isn&#x27;t customised) - double-checking now they currently only talk about importing SQLite3 dumps or compatible .sql files, not actually that it <i>is</i> SQLite.<p>So API changes like this actually break that promise don&#x27;t they? Even though you wouldn&#x27;t normally think of an addition (of `jsonb_*` functions) as being a major change (and I know it isn&#x27;t semver anyway) they are for Cloudflare&#x27;s promise of being able to import SQLite-compatible dumps&#x2F;query files, which wouldn&#x27;t previously have but henceforth might contain those functions.
评论 #38543255 未加载
evanjrowley超过 1 年前
I&#x27;m familiar with MongoDB&#x27;s BSON, but not JSONB. Here is an article I found that talks about the differences: <a href="https:&#x2F;&#x2F;blog.ferretdb.io&#x2F;pjson-how-to-store-bson-in-jsonb&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;blog.ferretdb.io&#x2F;pjson-how-to-store-bson-in-jsonb&#x2F;</a>
评论 #38541877 未加载
kevin_thibedeau超过 1 年前
Next step is to go full Ouroboros and have embedded SQLite DBs as records.
评论 #38540651 未加载
评论 #38540643 未加载
bvrmn超过 1 年前
Despite internal format I see immediate external usage in applications. For example batch insertions in Python. Per row insert call has noticeable overhead. And JSONB could bring performance back with CTE:<p><pre><code> CREATE TABLE data(id, name, age); WITH ins AS ( SELECT c1.value, c2.value, c3.value FROM json_each(&#x27;[&quot;some&quot;, &quot;uuid&quot;, &quot;key&quot;]&#x27;) c1 INNER JOIN json_each(&#x27;[&quot;joe&quot;, &quot;sam&quot;, &quot;phil&quot;]&#x27;) c2 USING (id) INNER JOIN json_each(&#x27;[10, 20, 30]&#x27;) c3 USING (id) ) INSERT INTO data (id, name, age) SELECT * FROM ins </code></pre> Each json_each could accept a bind parameter with JSONB BLOB from an app.
评论 #38541299 未加载
radarsat1超过 1 年前
I have some cases where sometimes I want to store a vector of floats along with a data item. I usually don&#x27;t need to match against the column, just store it. I know I could use BLOB but often I just use JSON for this kind of thing so that I don&#x27;t have to deal with data types and conversion. It&#x27;s wasteful and imprecise though due to the string conversion. Is JSONB a good middle ground option for these cases?<p>Edit: Sorry, just saw the comment below by o11c,<p>&gt; Sqlite&#x27;s JSONB keeps numbers as strings<p>which means the answer to my question is basically &quot;no&quot;.
sjmiller609超过 1 年前
I wish there was some way to compress JSON data across multiple rows, I often have very similar blobs in each row. Or some other way to reduce amount of storage for a lot of similar blobs across many rows, for example 10kB JSON where only one or two keys are different.
yencabulator超过 1 年前
This does not look at all usable. Your application is exposed to the &quot;internal binary format&quot; that SQLite has chosen:<p><pre><code> select jsonb_extract(&#x27;{&quot;foo&quot;: {&quot;bar&quot;: 42}}&#x27;, &#x27;$.foo&#x27;); ┌────────────────────────────────────────────────┐ │ jsonb_extract(&#x27;{&quot;foo&quot;: {&quot;bar&quot;: 42}}&#x27;, &#x27;$.foo&#x27;) │ ├────────────────────────────────────────────────┤ │ |7bar#42 │ └────────────────────────────────────────────────┘</code></pre>
1vuio0pswjnm7超过 1 年前
&quot;The central idea behind this JSONB specification is that each element begins with a header that includes the size and type of that element.&quot;<p>Why not add this size indication to JSON specification. Would reduce memory requirements for JSON processing.<p>1997: <a href="https:&#x2F;&#x2F;cr.yp.to&#x2F;proto&#x2F;netstrings.txt" rel="nofollow noreferrer">https:&#x2F;&#x2F;cr.yp.to&#x2F;proto&#x2F;netstrings.txt</a><p>NB. This header may be the &quot;central idea&quot; behind JSONB but JSONB has other differences from JSON. This comment refers only to the size indication not the other features.
DonHopkins超过 1 年前
Would be nice to have an even more compact csv-esque version of jsonb that knew how to store arrays of objects with the same keys in compressible column-major format, omitting the repeated keys (and even value types if possible), like a transposed csv file with a first column of headers + type info. And the ability to embed arrays of object encoded that way into arbitrary jsonb structures, as long as all the objects have the same keys and (simple enough) value types. Or is that what the (different?) Postgres jsonb format does?
filereaper超过 1 年前
JSONB has performance implications, many of you here are likely familiar with JSONB in Postgres.<p>I encourage you to view this talk from PGConf NYC 2021 - Understanding of Jsonb Performance by Oleg Bartunov [1]<p>Looking forward to a similar talk from the SQLite community on JSONB performance in the future.<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=v_s-DH4PEVA" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=v_s-DH4PEVA</a>
SigmundA超过 1 年前
I would prefer relational databases just have a compound hierarchal data type that can contain all the types it supports. Json is so anemic on types.<p>This way it can efficiently store numbers , dates, uuids or raw binary etc. and should really have some sort of key interning to efficiently store repeating key names.<p>Then just have functions to convert to&#x2F;from json if thats what you want
评论 #38546591 未加载
chubot超过 1 年前
Hm I googled and found this draft of the encoding - <a href="https:&#x2F;&#x2F;sqlite.org&#x2F;draft&#x2F;jsonb.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;sqlite.org&#x2F;draft&#x2F;jsonb.html</a><p>It feels like it would be better to use a known binary encoding. I thought the MessagePack data model corresponded pretty much exactly to JSON ?<p>Edit: someone else mentioned BSON - <a href="https:&#x2F;&#x2F;bsonspec.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;bsonspec.org&#x2F;</a><p>To be honest the wins (in this draft) don&#x27;t seem that compelling<p><i>The advantage of JSONB over ordinary text RFC 8259 JSON is that JSONB is both slightly smaller (by between 5% and 10% in most cases) and can be processed in less than half the number of CPU cycles.</i><p>JSON has been optimized to death; it seems like you could get the 2x gain and avoid a new format with normal optimization, or perhaps compile-time options for SIMD JSON techniques<p>---<p>And this seems likely to confuse:<p><i>The &quot;JSONB&quot; name is inspired by PostgreSQL, but the on-disk format for SQLite&#x27;s JSONB is not the same as PostgreSQL&#x27;s. The two formats have the same name, but they have wildly different internal representations and are not in any way binary compatible. </i><p>---<p>Any time data is serialized, SOMEBODY is going to read it. With something as popular as sqlite, that&#x27;s true 10x over.<p>So to me, this seems suboptimal on 2 fronts.
评论 #38540711 未加载
评论 #38540707 未加载
评论 #38541026 未加载
评论 #38546848 未加载
评论 #38540657 未加载
评论 #38540654 未加载
评论 #38551313 未加载
mongol超过 1 年前
Unrelated question: what languages integrates best with sqlite? I am using it with go and cgo, but it is often advised to avoid cgo. Perhaps it doesn&#x27;t matter so much, I can use it anyways, but would be interesting to hear about other experiences.
评论 #38552729 未加载
评论 #38543948 未加载
评论 #38545722 未加载
评论 #38542479 未加载
cryptonector超过 1 年前
I&#x27;m surprised that TFA doesn&#x27;t say that the JSONB it refers to is PostgreSQL&#x27;s JSONB. I assume it must be because SQLite3 adopts a lot of things from PostgreSQL, so D.R. Hipp and crew must be familiar with PG&#x27;s JSONB and so they wouldn&#x27;t create a different JSONB. Plus the PG JSONB is <i>brilliant</i>, so it would be wise to copy it or at least take inspiration from it.<p>There&#x27;s.. no need to interop with PG&#x27;s JSONB encoding, I think. If so then SQLite3&#x27;s could differ from PG&#x27;s.<p>Anyways, it&#x27;d be nice if TFA was clearer on this point.<p>EDIT: <a href="https:&#x2F;&#x2F;sqlite.org&#x2F;draft&#x2F;jsonb.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;sqlite.org&#x2F;draft&#x2F;jsonb.html</a> does refer to PG&#x27;s JSONB, and says that they are different.
euroderf超过 1 年前
So what will JSONB look like in a standalone DB browser (DBeaver, etc.) ?
评论 #38548885 未加载
lovasoa超过 1 年前
As the maintainer of sql.js and SQLPage, I am very excited about this:<p>- json is used a lot by sql.js users to interact with JavaScript.<p>- to generate more sophisticated web pages in SQLPage, json is crucial<p>I can&#x27;t wait for the next release !
array-species超过 1 年前
Interested to know what the Deno JavaScript&#x2F;TypeScript project thinks of this addition given it has already has a key value store backed by the database and JSON is JavaScript friendly.
评论 #38540717 未加载
Animats超过 1 年前
Is this just a data type, or did SQLite put in a JSON interpreter?
评论 #38540741 未加载
评论 #38541205 未加载
评论 #38541037 未加载
评论 #38540982 未加载
评论 #38546610 未加载
nojs超过 1 年前
What are the use cases for storing and manipulating json at the db level like this - why not use a relational schema and query it in the normal way?
评论 #38542469 未加载
评论 #38542540 未加载
评论 #38544676 未加载
ckok超过 1 年前
Does anyone know if SQLite has a public roadmap? This combined with a gin or gin like index would be a killer combination
ape4超过 1 年前
Does Sqlite support Sqlite database format in tables
gymbeaux超过 1 年前
What’s the difference between JSONB and BSON?
mgaunard超过 1 年前
why not decode it as a struct or list of whatever are the native types in the database for arbitrarily nested objects?
评论 #38547812 未加载
hoerzu超过 1 年前
Is there any best practices around jsonb?
p-e-w超过 1 年前
There&#x27;s all the rest of open source, and then there&#x27;s SQLite. A public domain software that doesn&#x27;t accept contributions from outsiders, and that happens to run much of the world.<p>And it just keeps getting better and better and better, and faster and faster and faster.<p>I don&#x27;t know <i>how</i> these guys manage to succeed where almost all other projects fail, but I hope they keep going.
评论 #38541017 未加载
评论 #38540804 未加载
评论 #38540884 未加载
评论 #38546647 未加载
评论 #38541327 未加载
评论 #38540693 未加载
downrightmike超过 1 年前
Is it an excellent and unchecked attack surface like JSON is in MSSQL? Postgres is also known for SQL injection. And if this is based off of that...<p><a href="https:&#x2F;&#x2F;www.imperva.com&#x2F;blog&#x2F;abusing-json-based-sql&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.imperva.com&#x2F;blog&#x2F;abusing-json-based-sql&#x2F;</a>
评论 #38540810 未加载