Home » Posts tagged "data"

從 Microsoft SQL Server 轉移到 PostgreSQL 的工具

在「How to Migrate from Microsoft SQL Server to PostgreSQL」這邊看到作者的客戶需要把 Microsoft SQL Server 轉移到 PostgreSQL (但沒有提到原因)。

裡面主要是兩個階段的轉換,第一個階段是 schema 的轉換,作者提到了 dalibo/sqlserver2pgsql 這個用 Perl 寫的工具:

Migration tool to convert a Microsoft SQL Server Database into a PostgreSQL database, as automatically as possible http://dalibo.github.io/sqlserver2pgsql

第二個階段是資料的轉換,是選擇用 Pentaho Data Integration 的 Community Edition:

Pentaho offers various stable data-​centric products. Pentaho Data Integration (PDI) is an ETL tool which provides great support for migrating data between different databases without manual intervention. The community edition of PDI is good enough to perform our task here. It needs to establish a connection to both the source and destination databases. Then it will do the rest of work on migrating data from SQL server to Postgres database by executing a PDI job.

所以用兩個工具串起來... 另外在文章裡面沒提到 stored procedure 之類的問題,應該是他們的客戶沒用到或是很少用到?

DynamoDB Autoscaling 的各種眉眉角角...

AdRollDynamoDB Autoscaling 的踩雷記錄,裡面有些資訊如果不是跳下去玩應該不會注意到 (魔鬼藏在細節裡的感覺):「Managing DynamoDB Autoscaling with Lambda and Cloudwatch」。

第一個提到的問題是 autoscaling 的觀察對象:

Ideally, the table should scale based on the number of requests that we are making , not the number of requests that are successful.

另外一個是 autoscaling 遇到完全不用的情況下不會 scale down,看起來是某種保護機制。但這使得平常只有拿來讀取的表格在跑完 batch job 後得自己處理 write scale down 問題:

Additionally, at the time of implementing this algorithm, the DynamoDB capacity could not be brought down automatically if the consumption was exactly zero, which can happen if you write to your table in batch instead of realtime, for example.

This meant that, when enabling autoscaling, tables that were read in realtime, but written to in batch, still needed manual intervention to bring the write capacity down after our jobs were done writing.

另外一個問題是 scale down 是有次數限制的:

Another interesting point that might bite users is that capacity decreases are an expensive operation for AWS, so they’re limited.

The number of decreases cited in the documentation can be achieved under very special conditions, since you need to have 4 decreases in the first hour of the day plus one for each of the remaining hours, for a total of 4 (first hour) + 23 (1 hourly) = 27.

後面就是自己研究什麼 algorithm 可以調整的更細,然後用 lambda 重寫... 最後省下 30% 的成本:

Here is where we detected our costs for our batch tables dropping to around 30% of the initial cost.

AdRoll 的規模應該是不小,所以為了省 30% 可以花不少力氣在上面...

把 b-mobile 的おかわりSIM 換成 190PadSIM 了

因為有養一個日本號碼的需求 (收簡訊),加上去日本時希望可以有個當地的上網方案,可以在還沒到民宿時使用 (不少民宿會提供分享器讓你帶出去),所以當初辦了 b-mobile 的「b-mobile おかわりSIM 5段階定額」這個方案:第一次的設定費是 JPY¥3000,之後每個月基本費用是 JPY¥630,方案包含了每個月 1GB 的流量,可以付費使用到 5GB 的流量 (額外多收 JPY¥250/GB),用完後限速 200kbps。

一開始的速度不太行,就當作養門號用:「b-mobile 的おかわり的速度」,但後來幾次去日本發現好不少 (Twitch 的 720p 也還看的動),就當作是去日本的網路方案之一了 (會準備備案在需要的時候啟用)。這個方案後來停止申請了,但原來的申請者還是可以繼續用。

後來推出的方案是「b-mobile S 190PadSIM」,從名稱可以看出是設計給平板用的。一樣是 JPY¥3000 的設定費用,但之後每個月的基本費用降到 JPY¥190,不過這個方案只包括了 100MB 的流量,但因為是設計給 Pad 使用者,所以方案設計可以付費使用到 15GB 的流量 (分階段是 JPY¥480/1GB,JPY¥850/3GB,JPY¥1450/6GB,JPY¥2190/10GB 與 JPY¥3280/15GB)。

這個方案就流量單價來說比おかわりSIM 便宜 (差不多是 JPY¥200/GB 上下),不過對於流量在 1GB~2GB 與 3GB~5GB 的部份會變得比較貴,所以切過去也不一定比較好。但可以看到因為基本費用變低不少,對於養門號的人來說省了不少...

先前以為需要重新辦一張卡,就一直沒有動力處理 (設定費用與弄回台灣的成本),直到登入到 b-mobile 後台後發現可以直接改服務就改過去了,要注意的是改完後下個 cycle 才會是新的方案。

Google 也透過同樣機制蒐集使用者的行為

Update:Google 的憑證也被 revoke 了,另外 Facebook 的恢復內部使用的部分了:「Apple blocks Google from running its internal iOS apps」。

昨天是 Facebook 被發現在 iOS 上使用 Enterprise Certificate 取得使用者的行為記錄 (參考「Facebook 花錢向使用者購買他們的行為記錄」),後來 Apple 撤銷了這張 Enterprise Certificate (因為不符合 Enterprise Certificate 的使用條款),並且使得 Facebook 內部符合 Enterprise Certificate 的應用程式都失效。

Google 也被抓出幹同樣的事情,叫做 Screenwise Meter:「Google will stop peddling a data collector through Apple’s back door」。

目前 Google 自己已經下架,但這表示已經有的 spyware 還是會生效,就看 Apple 要不要拔了...

Twitter 搬上 Google Cloud

Twitter 要搬上 Google Cloud Platform 了,而 Google 直接把這個消息用最漂亮的 url 發佈:「Twitter migrates data to Google Cloud to keep the world tweeting」。

裡面也提到了一些數字,像是 Twitter 使用的空間:

To keep processing massive amounts of data 24/7, the social media platform was expecting to transfer over 300 petabytes of data storage to the cloud.

另外實際用 mtr 跑,看起來 twitter.com 前面還是 Twitter 自家機房的 proxy,所以應該是後面的架構搬上去?

Percona 推出 MySQL 8.0 的對應版本了...

Percona 在過節前推出 Percona Server for MySQL 8.0 了:「Announcing General Availability of Percona Server for MySQL 8.0」。

Oracle 版的 MySQL 8.0 多了不少功能,像是往 NoSQL 靠的功能與 GIS 相關的功能,但讓我注意到的是 Percona 自己的事情... TokuDB 因為 MyRocks 而要被放生了:

Features Being Deprecated in Percona Server for MySQL 8.0
TokuDB Storage Engine: TokuDB will be supported throughout the Percona Server for MySQL 8.0 release series, but will not be available in the next major release. Percona encourages TokuDB users to explore the MyRocks Storage Engine which provides similar benefits for the majority of workloads and has better optimized support for modern hardware.

HyperLogLog 與 Bloom Filter

看到 FacebookPresto 裡增加使用 HyperLogLog 計算數量的能力,突然想到常常忘記這兩個拿準確度換速度的資料結構:「HyperLogLog in Presto: A significantly faster way to handle cardinality estimation」。

HyperLogLog (HLL) 是解決 Count-distinct problem 的資料結構,用很少的記憶體就可以給出一個誤差不大的值 (用 1.5KB 的空間處理十億等級的資料,誤差大約在 2%),所以 Presto 利用這個資料結構引進了 APPROX_DISTINCT() 以及其他的函數,就很容易在 L2/L3 cache 裡運算,藉此大幅提昇速度。

Depending upon the problem at hand, we can achieve speed improvements of anywhere from 7x to 1,000x.

先前也提過 Reddit 也用 HLL 統計資料:「Reddit 在處理 Page View 的方式」。

Bloom Filter 也是在處理大量資料的問題,但這個資料結構的功能不太一樣,是給出「有沒有存在」,使用空間與誤差大約是 10 bits per key (1% false positive),另外先前也有提到一些變形,可以提供其他功能。像是「Quotient filter」與「Cuckoo Filter:比 Bloom Filter 多了 Delete」。

CloudFront 在北美增加了一堆節點...

CloudFront 在北美增加了一堆節點:「Amazon CloudFront announces ten new Edge locations in North America, Europe, and Asia」。

北美一口氣增開了八個,提升了 40% 的 capacity:

Amazon CloudFront announces ten new Edge locations, adding to our global presence. Eight of the new Edge locations are in North America: Houston, Texas (our first location in this city), Chicago, Illinois, Newark, New Jersey, Los Angeles, California, and Ashburn, Virginia. We also added an Edge location in Berlin, Germany, as well as one in Tokyo, Japan.

With this launch, CloudFront will increase its request processing capacity by up to 40%, on average, in the North American cities.

另外不怎麼意外的又增加了東京...

AWS 給 EBS 用的 Data Lifecycle Manager 在東京可以用了?

先前在「Amazon EBS Snapshot 支援 Lifecycle Management」這邊提到 AWS 設計了 Data Lifecycle Manager,讓 EBS 磁碟可以自動產生 snapshot 並且管理保留份數,可以當作某種備份機制。

七月公告當時只開放了少數幾區:

Availability – Data Lifecycle Manager is available in the US East (N. Virginia), US West (Oregon), and Europe (Ireland) Regions.

剛剛發現在東京也已經可以用了?但好像沒看到有公告提過... 設下去看看會不會動好了。

Archives