|
Handling @percolate's data in New York City
|
California-based Vaurum, a company that offers financial institutions a way to trade and store bitcoins, has raised $4m in venture capital.
The investment is described as a seed round and comes from a group of investors that includes VC firm Battery Ventures, Tim Draper and former AOL CEO Steve Case.
Avish Bhama, Vaurum CEO, said in a prepared statement:
Apple’s latest operating system for iOS is a departure from their old aesthetic. So I’ve decided to give the NewsBlur iOS app a slightly new look. But even more than how the app looks is how the app works. Tons of new features made it into this mega-release.
The iPad app also has a new view for extra-wide reading while in portrait orientation.
I hope you enjoy this latest update. And stay tuned for the next update coming soon which will include even more iOS 7 features: Dynamic Text Size and Background Updates. The NewsBlur iOS app is and will always be free.
While I love shipping new features and fixing bugs, the single largest user request was neither a feature nor a bug. NewsBlur allows for two weeks of unread stories. Once a story is more than 14 days old, it would no longer show up as unread. The justification for this was simple: you have a week to read a story, and have a second week as a grace period.
But after scaling out to tens of thousands of users, a new pattern emerged. Some users would go on vacation for two weeks at a time and then want to catch up on everything they missed. Some users only check RSS once a month. Some users just want to leave lightly updated feeds alone until they have free time to read them, and that can take a few weeks to get to.
Starting today, all premium users are automatically upgraded to 30 days of unread stories. Free standard users will remain at 14 days. I wish I could have offered the full 30 days to everybody, but after testing that out, my server and performance graphs all made a very scary movement up.
With the new 30 day unread interval in place, NewsBlur has a great track record in listening to user feedback and working out a solution, however large the task may be.
The Amazon Relational Database Service (RDS) handles all of the messy low-level aspects of setting up, managing, and scaling MySQL, Oracle Database, and SQL Server databases. You can simply create an RDS DB instance with the desired processing power and storage space and RDS will take care of the rest.
The RDS Provisioned IOPS feature (see my recent blog post for more information) gives you the power to specify the desired number of I/O operations per second when you create each DB instance. This allows you to set up instances with the desired level of performance while keeping your costs as low as possible.
Today we are introducing three new features to make Amazon RDS even more powerful and more scalable:
Let's take an in-depth look at each of these new features.
Up to 3 TB of Storage and 30,000 Provisioned IOPS
We
are tripling the amount of storage that you can provision for each DB
instance, and we're also tripling the number of IOPS for good measure.
You can now create DB instances (MySQL or Oracle) with up to 3 TB of storage (the previous limit was 1 TB) and 30,000 IOPS (previously, 10,000). SQL Server DB Instances can be created with up to 1TB of storage and 10,000 IOPS.
For a workload with 50% reads and 50% writes running on an m2.4xlarge instance, you can realize up to 25,000 IOPS for Oracle and 12,500 IOPS for MySQL. However, by provisioning up to 30,000 IOPS, you may be able to achieve lower latency and higher throughput. Your actual realized IOPS may vary from what you have provisioned based on your database workload, instance type, and choice of database engine. Refer to the Factors That Affect Realized IOPS section of the Amazon RDS User Guide to learn more.
Obviously, you can work with larger datasets, and you can read and write the data faster than before. You might want to start thinking about scaling PIOPS up and down over time in response to seasonal variations in load. You could also use a CloudWatch alarm to make sure that you are the first to know
You can modify the storage of existing instances that are running MySQL or Oracle Database. When you do this you can grow storage by 10% or more, and you can raise and lower PIOPS in units of 1,000. There will be a performance impact while the scaling process is underway.
Conversion from Standard Storage to Provisioned IOPS Storage
You can convert DB instances with Standard Storage to Provisioned IOPS in order to gain the benefits of fast and predictable performance. You can do this from the AWS Management Console, the command line, or through the RDS APIs. Simply Modify the instance and specify the desired number of PIOPS.
There will be a brief impact on availability when the modification process starts. If you are running a Multi-AZ deployment of RDS, the availability impact will be limited to the amount of time needed for the failover to complete (typically three minutes). The conversion may take several hours to complete and there may be a moderate performance degradation during this time.
Note: This feature is applicable to DB instances running MySQL or Oracle Database.
Independent Scaling of IOPS and Storage
You can now scale Provisioned IOPS and storage independently. In general, you will want to have between 3.0 and 10.0 IOPS per GB of storage. You can modify the ratio over time as your needs change.
Again, this feature is applicable to DB instances running MySQL or Oracle Database.
Available Now
All three of these features are available now, and they are available in every AWS Region where Provisioned IOPS are supported (all Regions except AWS GovCloud (US)).
You can use these features in conjunction with RDS Multi-AZ deployments and RDS Read Replicas.
-- Jeff;
Log in
reply
