Home » Posts tagged "object"

JSON 的 Object 裡 Key 重複的問題

tl;dr:不要亂來啦... 這是 UB (Undefined behavior) 的一種。

因為看到這則 tweet,所以去查一下 JSON 的資料:

首先是找標準是什麼。在維基百科的 JSON 條目裡提到了有兩份標準,一份是 RFC 7159,一份是 ECMA-404

Douglas Crockford originally specified the JSON format in the early 2000s; two competing standards, RFC 7159 and ECMA-404, defined it in 2013. The ECMA standard describes only the allowed syntax, whereas the RFC covers some security and interoperability considerations.

ECMA-404 裡面就真的只講語法沒講其他東西,而在 RFC 7159 內的 Object 則是有提到 (重點我就用粗體標起來了):

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique.

   object = begin-object [ member *( value-separator member ) ]
            end-object

   member = string name-separator value

An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.

JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.

粗體有描述唯一性,但尷尬的地方在於他用 SHOULD 而非 MUST,所以 library 理論上都要能接受。但後面提到如果不唯一時,行為無法預測 (會到 rm -rf / 嗎?XDDD 最像的應該還是 crash?),所以還是不要亂來啦...

不過如果真的會 crash 的話,應該也會因為 DoS issue 而被發 CVE,所以實務上應該是不會 crash 啦...

PHP 7.3 的 json_decode() 將會用 Exception 處理錯誤

在「PHP: rfc:json_throw_on_error」這邊提到 PHP 7.3 會解決 json_decode() 發生錯誤時的處理方式:

PHP has two functions for dealing with JSON, json_decode() and json_encode(). Unfortunately, both have suboptimal error handling. json_decode() returns null upon erroring, but null is also a possible valid result (if decoding the JSON “null”).

在這之前唯一的判斷方式是另外再呼叫 json_last_error() 或是 json_last_error_msg(),但這樣寫很辛苦,所以要引入 JsonException 了,總算...

有 Lazy Connection 功能的 PDO object

在「Aura.Sql」這邊看到有提供 Lazy Connection 的 PDO object,而且是繼承自本來的 PDO object:

Provides an extension to the native PDO along with a profiler and connection locator. Because ExtendedPdo is an extension of the native PDO, code already using the native PDO or typehinted to the native PDO can use ExtendedPdo without any changes.

Lazy connection. ExtendedPdo connects to the database only on method calls that require a connection. This means you can create an instance and not incur the cost of a connection if you never make a query.

之後可以拿來跟 LaravelEloquent 一起用看看。本來的 PDO 物件在建立時就會建立連線,對於連線的開銷其實蠻大的,用這個應該是個方向...

另外是 Profiler 的能力,需要用的時候應該會很好用:

Profiler. An optional query profiler is provided, along with an interface for other implementations, that logs to any PSR-3 interface.

引一下來源,當初是從「Atlas.Orm 2.0 Is Now Stable」這邊在看文件時一路看到的。

AWS Storage Gateway 的新功能:File Gateway

AWS Storage Gateway 推出新功能 File Gateway:「File Interface to AWS Storage Gateway」。

可以讓使用者在前面用 NFS,後面實際接的是 Amazon S3

After you set it up in your data center or in the cloud, your configured buckets will be available as NFS mount points. Your application simply reads and writes files and directories over NFS; behind the scenes, the gateway turns these operations into object-level requests on your S3 buckets, where they are accessible natively (one S3 object per file).

以前自己用 FUSE 惡搞的方式,現在變成官方支援的功能?XDDD

Amazon S3 的改善

其實老牌的 Amazon S3 也改了不少東西:「Revolutionizing S3 Storage Management with 4 new features」。

其中的「S3 Object Tagging」讓管理可以透過 tag 處理,管理上會多一些選擇。而「S3 Analytics, Storage Class Analysis」則是可以分析存取的 pattern,藉此重新規劃 policy。

看到之前的同事說 CloudFront 要支援 2-tier cache,但卻還沒看到公告,不知道是怎麼樣的實作方式... 這對大型的 live streaming 幫助很大啊,後面的壓力會小很多。

幽浮 XDDD

拿 1000W 的 LED 裝在無人機上... 等下,你挑的 LED 燈的顏色跟裝上去的方法都怪怪的 XDDD

PS:大約在 50 秒的地方。

Amazon S3 的改善

在「Amazon S3 Introduces New Usability Enhancements」這邊提到了 Amazon S3 的兩個改善。

第一個是業務面的改善,以前應該是開 support ticket 請人調整 S3 bucket 數量上限,現在則是可以直接透過界面申請?(沒有遇過瓶頸,不知道以前是不是在界面上看不到...)

第二個才是重頭戲:Read-after-write Consistency。

With this enhancement, Amazon S3 now supports read-after-write consistency in all regions for new objects added to Amazon S3.

也就是說,Amazon S3 現在保證「新增的 object」「可以在建立後馬上被讀取」。之前還沒修正前,這個問題有多嚴重呢?可以看 2014 年時「Netflix 對 S3 的 Eventually Consistency 的補強...」這邊 Netflix 在跑 PigHive 遇到的問題。

Netflix 這邊舉的例子是兩個 Pig cluster 在跑,其中 Pig-2 需要 Pig-1 跑出來的資料,在這次公告前,如果 Pig-1 的資料寫回 Amazon S3 時不會馬上出現,那麼 Pig-2 就會拿不完整的資料執行:

Pig-2 is activated based on the completion of Pig-1 and immediately lists the output directories of the previous task. If the S3 listing is incomplete when the second job starts, it will proceed with incomplete data.

而現在總算是保證新的 object 可以馬上被讀取,所以 Netflix 可以利用一個檔案列出所有的 filename,確保知道所有的檔案名稱... (LIST 指令還是 eventually consistent,所以這部份還是要自己處理)

資料結構、RDBMS、ORM

欠了很久的雜記。既然是雜記,只是把一些事情記錄下來,許多句子的主題會跳來跳去,請多見諒。

先解釋標題的三個詞彙。這邊要講的是三種存取資料的方式:

  • 資料結構:直接操作最底層的資料結構。
  • RDBMS (Relational Database Management System,關聯式資料庫):透過 RDBMS 存取資料的方式,在 open source 領域比較常遇到 MySQLPostgreSQL。由於與下面的 ORM 比較,這一條指的是透過 SQL query 去存取資料。
  • ORM (Object-Relational Mapping):透過程式語言的 object 以及 object 之間的關聯性存取資料。

彈性最高、效能也最好的是直接的資料存取,但寫起來也最複雜;而 ORM 大致上就是反過來。

現代的 RDBMS 大多都有實做 ACID,在自己操作資料結構時考慮這塊會比較辛苦。兩個層級之間有一些 library 試著解決這個問題 (像是 BerkeleyDB 或是 LevelDB),不過這篇文章暫時跳過。

MySQL 與其他的 RDBMS 比較起來欠了許多東西,但 High Availability 的成熟度以及效能而成為 open source 的第一選項。而也因為許多人使用,大家都知道 MySQL 的先天限制,也有許多 workaround 出現,所以大多數的狀況下這不是問題。

MySQL 的 InnoDB 其實寫的相當不錯,但 MySQL 的 SQL parser 一直都是 MySQL 的痛處,所以許多人使用 MySQL 時會儘量使用 simple query,而 ORM 的特性剛好可以搭上風。

使用 ORM 時最常見要避免的是 N+1 的問題,其他常見到的問題大多都不是 ORM 專有的。

先整理到這邊。

Archives