�ݺ�ߣ

Editor's Notes

1. Our data problems are one type of big data problem. We have lots of data, but at least they are mostly of a known structure. Still, the problem of dealing with that much data in a way that allows rapid access and update is a challenge. Our Pedigree database is now North of 15 TB. We have more than 20 TB of historical record data. Our record images at the relatively low resolution and quality level that we publish on the Internet still amount to more than 2 PB. And access rates continue to increase to support more users, more uses. Having the ability to scale our systems up and down is crucial to handling these challenges.
2. We can’t afford to have system outages cause our patrons and your customers to wait, or worse, to be denied access. High redundancy built into our systems at every component level is a must. To achieve this, we need a scalable, dynamic, and highly resilient environment for our systems to run in. Hence the aws cloud.
3. Getting our customers inside our applications, or inside yours that depend on our system availability is crucial to us. Once there, we need to be able to give each person access to the information available, and do it in a way that keeps their interest, satisfies their desire, and brings them back for more.
4. Besides localizing our applications into 40 languages, we are trying to understand what makes FH interesting and relevant in various parts of the world. Future support for Jai Pu, or for clan association are some things we are considering.
5. Jai Pu represent genealogical data rather differently than how we visualize it in the western world. Direct support for such visualization enhances the cultural acceptance.
6. We already have a world-wide reach with our products. However, they are very much centrally run in the Eastern United States. The experience for someone accessing our site across the Internet from Kenya is much different than from the Western Hemisphere. Solutions include replicating and distributing our systems into regional centers to place them closer to the patrons.
7. Throughout a 24 hour period, our user load ranges between 8000 and 32000. The trend is sloping upwards at a good clip. Add to that the user generated traffic that hits our site from partners’ tools and the load becomes quite tricky to manage. We keep adding infrastructure elements to help out, but it’s difficult to keep up. And besides, this represents a four-fold increase between lowest and highest traffic within 24 hours. Sizing for peak X k is very expensive. Here again, dynamic infrastructure can help us.
8. While we have had large parts of our web site running in the Amazon cloud for better than four years, we are now moving more and more workloads into the cloud. Let’s take a look at some of the things we are seeing with this.
9. Ability to get compute on demand enables us to do this job in reasonable time. Pulling some tricks such as spot instances saves us lots of money.
10. Dynamic infrastructure enables new approaches to large data problems such as ETL.
11. Accessibility here means programmer accessibility to our APIs or services. Not everyone is interested in managing HTTP and understanding HATEOAS
12. Be sure to attend Dallan’s talk Thursday on “Javascript SDK” and Friday on “Javascript Reference Client”
13. Of course there have been many attempts at some of this: Gedcom, GedML, Gentech… But none enjoys wide and modern support while representing the types of data and media that are common today. This is why we created GedcomX. Is it a standard? Perhaps not in the strictest sense. But we would like to propose it as a working model toward such a standard.
14. As a data transfer specification, GedcomX facilitates computer reasoning on both conclusions and source data.
15. Because we have a common way to express historical record data and conclusion data, we can write programs to reason about them.